pkoppstein

Batch #3 (actually just one comment!) 13) Re: > When using input, it is generally necessary to invoke jq with the -n command-line option, otherwise the first entity will be...

@wader wrote: > also i think personally i would rather merge early, as it includes so many improvements I wholeheartedly agree. In particular, I hope that any potential revisions regarding...

@wader - Yes, long overdue.

@01mf02 - A tiny enhancement request whenever you get around to it: The very first line in the subsection on Modules currently reads: > jq has a library/module system. Modules...

@joelpurra asks: > Thoughts? 1. To use a new flag, you'd have to understand it; to use jq's ".foo" functionality, you have to understand it. So, in essence, adding a...

As a practical matter, I think the best approach to dealing with the "one hour wasted" problem that seems to be at the root of the issue here is a...

1. I've reproduced the problem using v1.0.1-dev4226 2. I believe the bug is closely associated with the use of `unnest` here. For example, there's no problem with the similar query:...

@Mytherin - You changed the title from CASE-statement does not short-circuit UNNEST evaluation to UNNEST should not be allowed within CASE statements But is that the appropriate conclusion? Consider: ```...

@wader wrote: > we're usually quite conservative with adding new functions. Not so long ago, there was a major performance issue that justified such conservatism. It's my understanding that the...

@bartgrantham - Later versions produce the same (confusing) error message, e.g. ``` $ jq --version jq-1.4-100-g0f89270 $ echo "{'foo':'bar'}" | jq .foo parse error: Invalid numeric literal at line 1,...