Peter Eisentraut writes:
> On 2019-09-20 01:14, Tom Lane wrote:
>> Sure. But we also modeled those features on the same language that the
>> committee is looking at (or at least I sure hope we did). So it's
>> reasonable to assume that they would come out at the same spot without
>> any promptin
On 2019-09-20 01:14, Tom Lane wrote:
> Chapman Flack writes:
>> Sure, against *every* non-spec feature we have or ever will have, someone
>> /could/ raise a generic "what if SQL committee might add something pretty
>> similar in future".
>> But what we have in this case are specific non-spec featu
Chapman Flack writes:
> Sure, against *every* non-spec feature we have or ever will have, someone
> /could/ raise a generic "what if SQL committee might add something pretty
> similar in future".
> But what we have in this case are specific non-spec features (array, map,
> and sequence constructor
On 09/19/19 18:35, Tom Lane wrote:
> There remains the question of whether we should do something like
> requiring a "pg" prefix to allow access to the other nonstandard
> features we added to jsonpath. I see the point that the SQL committee
> might well add something pretty similar in future. B
Chapman Flack writes:
> But is that even the point? It's already noted in [1] that the standard
> calls for one style of regexps and we're providing another.
> It's relatively uncomplicated now to add some kind of distinguishing
> syntax for our posix flavor of like_regex. Yes, it would be a chan
On 6/18/19 12:51 PM, Oleg Bartunov wrote:
>> have 'pg lax $.map(x => x + 10)'.
>
> This is exactly what we were thinking about !
Perfect!
>> specify a POSIX re. Or, as like_regex has a named-parameter-like
>> syntax--like_regex("abc" flag "i")--perhaps 'posix' should just be
>> an extra keyword
On Sat, 1 Jun 2019, 16:41 Chapman Flack, wrote:
> Hi,
>
> We had a short conversation about this on Friday but I didn't have time
> to think of a constructive suggestion, and now I've had more time to
> think about it.
>
> Regarding the proposed PG 13 jsonpath extensions (array, map, and
> sequen
On 2019-Jun-01, Chapman Flack wrote:
> In either case, perhaps we should immediately add a way to identify a
> jsonpath as being PostgreSQL-extended. Maybe a keyword 'pg' that can
> be accepted at the start in addition to any lax/strict, so you could
> have 'pg lax $.map(x => x + 10)'.
>
> If we
Hi,
We had a short conversation about this on Friday but I didn't have time
to think of a constructive suggestion, and now I've had more time to
think about it.
Regarding the proposed PG 13 jsonpath extensions (array, map, and
sequence constructors, lambdas, map/fold/reduce, user-defined
function
