On Jan 25, 2024, at 11:03, Tom Lane wrote:
> I changed the preceding para to say "... check expressions are
> required in ...", which I thought was sufficient to cover that.
> Also, the tabular description of the operator tells you not to do it.
Yeah, that’s good. I was perhaps leaning into
"David E. Wheeler" writes:
> On Jan 24, 2024, at 16:32, Tom Lane wrote:
>> +
>> + Predicate check expressions are required in the
>> + @@ operator (and the
>> + jsonb_path_match function), and should not be
>> used
>> + with the @? operator (or the
>> +
On Jan 24, 2024, at 16:32, Tom Lane wrote:
> "David E. Wheeler" writes:
>
>> In any event, something to do with @@, perhaps to have some compatibility
>> with `jsonb @> jsonb`? I don’t know why @@ was important to have.
>
> Yeah, that's certainly under-explained. But it seems like I'm not
>
"David E. Wheeler" writes:
> In any event, something to do with @@, perhaps to have some compatibility
> with `jsonb @> jsonb`? I don’t know why @@ was important to have.
Yeah, that's certainly under-explained. But it seems like I'm not
getting traction for the idea of changing the behavior,
On Jan 21, 2024, at 14:58, David E. Wheeler wrote:
> I make this interpretation based on this bit of the docs:
Sorry, that’s from my branch. Here it is in master:
A path expression can be a Boolean predicate, although the SQL/JSON
standard allows predicates only in filters. This is
On Jan 21, 2024, at 14:52, David E. Wheeler wrote:
> This is the only way the different behaviors make sense to me. @? expects a
> set, not a boolean, sees there is an item in the set, so returns true:
I make this interpretation based on this bit of the docs:
PostgreSQL's implementation
On Jan 21, 2024, at 14:43, Tom Lane wrote:
> I don't entirely buy this argument --- if that is the interpretation,
> of what use are predicate check expressions? It seems to me that we
> have to consider them as being a shorthand notation for filter
> expressions, or else they simply do not
"David E. Wheeler" writes:
> On Jan 20, 2024, at 12:34, Tom Lane wrote:
>> It will take a predicate, but seems to always return true:
>>
>> regression=# select '{"a":[1,2,3,4,5]}'::jsonb @? '$.a[*] < 5' ;
>> ?column?
>> --
>> t
>> (1 row)
>>
>> regression=# select
"David E. Wheeler" writes:
> On Jan 20, 2024, at 12:34, Tom Lane wrote:
>> Surely we're not helping anybody by leaving that behavior in place.
>> Making it do something useful, throwing an error, or returning NULL
>> all seem superior to this. I observe that @@ returns NULL for the
>> path type
On Jan 20, 2024, at 12:34, Tom Lane wrote:
> It will take a predicate, but seems to always return true:
>
> regression=# select '{"a":[1,2,3,4,5]}'::jsonb @? '$.a[*] < 5' ;
> ?column?
> --
> t
> (1 row)
>
> regression=# select '{"a":[1,2,3,4,5]}'::jsonb @? '$.a[*] > 5' ;
> ?column?
>
On Jan 20, 2024, at 11:45, Tom Lane wrote:
> You sure about that? It would surprise me if we could effectively use
> a not-equal condition with an index. If it is only == that works,
> then the preceding statement seems sufficient.
I’m not! I just assumed it in the same way creating an SQL =
On Jan 20, 2024, at 12:34, Tom Lane wrote:
> Surely we're not helping anybody by leaving that behavior in place.
> Making it do something useful, throwing an error, or returning NULL
> all seem superior to this. I observe that @@ returns NULL for the
> path type it doesn't like, so maybe that's
So, overall reaction to this patch: I like the approach of defining
"predicate check expressions" as being a different thing from standard
jsonpath expressions. However, I'm not so thrilled with just saying
"don't use" one type or the other with different jsonpath functions.
According to my
"David E. Wheeler" writes:
> While you’re in there, Tom, would it make sense to fold in something like
> [this patch][1] I posted last month to clarify which JSONPath comparison
> operators can take advantage of a index?
> --- a/doc/src/sgml/json.sgml
> +++ b/doc/src/sgml/json.sgml
> @@ -513,7
On Jan 19, 2024, at 21:46, Erik Wienhold wrote:
> Interesting... copy-pasting the entire \set command works for me with
> psql 16.1 in gnome-terminal and tmux. Typing it out manually gives me
> the "unterminated quoted string" error. Maybe has to do with my stty
> settings.
Yes, same on macOS
On 2024-01-19 22:15 +0100, Tom Lane wrote:
> "David E. Wheeler" writes:
> > [ v7-0001-Improve-boolean-predicate-JSON-Path-docs.patch ]
>
> + \set json '{
>"track": {
> "segments": [
>{
>
> I find the textual change rather unwieldy, but the bigger problem is
> that this example
I wrote:
> I experimented with
> SELECT '
> ... multiline json value ...
> ' AS json
> \gexec
> but that didn't seem to work either. Anybody have a better idea?
Oh, never mind, \gset is what I was reaching for. We can make
it work with that.
regards, tom lane
"David E. Wheeler" writes:
> [ v7-0001-Improve-boolean-predicate-JSON-Path-docs.patch ]
I started to review this, and got bogged down at
@@ -17203,9 +17214,12 @@ array w/o UK? | t
For example, suppose you have some JSON data from a GPS tracker that you
- would like to parse, such
The following review has been posted through the commitfest application:
make installcheck-world: not tested
Implements feature: not tested
Spec compliant: not tested
Documentation:tested, passed
I took a look for this commit, it looks correct to me
On Oct 23, 2023, at 20:20, Erik Wienhold wrote:
> I thought that you may have missed that one because I saw this change
> that removes the article:
>
>> -In the strict mode, the specified path must exactly match the structure
>> of
>> +In strict mode, the specified path must exactly
On 2023-10-24 00:58 +0200, David E. Wheeler wrote:
> On Oct 22, 2023, at 20:36, Erik Wienhold wrote:
>
> > That's an AppleSingle file according to [1][2]. It only contains the
> > resource fork and file name but no data fork.
>
> Ah, I had “Send large attachments with Mail Drop” enabled. To me
On Oct 22, 2023, at 20:36, Erik Wienhold wrote:
> That's an AppleSingle file according to [1][2]. It only contains the
> resource fork and file name but no data fork.
Ah, I had “Send large attachments with Mail Drop” enabled. To me 20K is not big
but whatever. Let’s see if turning it off
On 2023-10-20 15:49 +0200, David Wheeler wrote:
> On Oct 19, 2023, at 23:49, Erik Wienhold wrote:
>
> > I don't even know what that represents, probably not some fancy file
> > compression.
That's an AppleSingle file according to [1][2]. It only contains the
resource fork and file name but no
On Oct 19, 2023, at 23:49, Erik Wienhold wrote:
> I don't even know what that represents, probably not some fancy file
> compression.
Oh, weird. Trying from a webmail client instead.
Best,
David
v5-0001-Improve-boolean-predicate-JSON-Path-docs.patch
Description: Binary data
On 2023-10-20 05:20 +0200, David E. Wheeler wrote:
> On Oct 19, 2023, at 10:49 PM, Erik Wienhold wrote:
>
> > Just wanted to take a look at v5. But it's an applefile again :P
>
> I don’t get it. It was the other times too! Are you able to save it
> with a .patch suffix?
Saving it is not the
On Oct 19, 2023, at 10:49 PM, Erik Wienhold wrote:
> Just wanted to take a look at v5. But it's an applefile again :P
I don’t get it. It was the other times too! Are you able to save it with a
.patch suffix?
D
On 2023-10-19 15:39 +0200, David E. Wheeler wrote:
> On Oct 19, 2023, at 01:22, jian he wrote:
>
> Updated patch attached and also on GitHub.
>
>
> https://github.com/postgres/postgres/compare/master...theory:postgres:jsonpath-pred-docs
Just wanted to take a look at v5. But it's an
On Oct 19, 2023, at 01:22, jian he wrote:
> "Do not use with non-predicate", double negative is not easy to
> comprehend. Maybe we can simplify it.
>
> 16933: value. Use only SQL-standard JSON path expressions, not not
> there are two "not".
>
> 15842: SQL-standard JSON path
On Tue, Oct 17, 2023 at 10:56 AM David E. Wheeler wrote:
>
>
> Oh, I thought it would report issues from the files they were found in.
> You’re right, I forgot a title. Fixed in v4.
>
> David
>
+Returns the result of a JSON path
+predicate
+check for the specified JSON
On Oct 16, 2023, at 18:07, Erik Wienhold wrote:
>> Okay, added, let’s just put all our cards on the table. :-)
>
> I'll have a look but the attached v3 is not a patch but some applefile.
Weird, should be no different from previous attachments. I believe Apple Mail
always uses
On 2023-10-16 21:59 +0200, David E. Wheeler write:
> On Oct 15, 2023, at 23:03, Erik Wienhold wrote:
>
> > Your call but I'm not against including it in this patch because it
> > already touches the modes section.
>
> Okay, added, let’s just put all our cards on the table. :-)
I'll have a look
On Oct 15, 2023, at 23:03, Erik Wienhold wrote:
> Your call but I'm not against including it in this patch because it
> already touches the modes section.
Okay, added, let’s just put all our cards on the table. :-)
>> Agreed. Would be good if we could teach these functions and operators
>> to
On 2023-10-16 01:04 +0200, David E. Wheeler write:
> On Oct 14, 2023, at 19:51, Erik Wienhold wrote:
>
> > Thanks for putting this together. See my review at the end.
>
> Appreciate the speedy review!
You're welcome.
> >> Follow-ups I’d like to make:
> >>
> >> 1. Expand the modes section to
On Oct 14, 2023, at 19:51, Erik Wienhold wrote:
> Thanks for putting this together. See my review at the end.
Appreciate the speedy review!
> Nice. This really does help to make some sense of it. I checked all
> queries and they do work out except for two queries where the path
> expression
On 2023-10-14 22:40 +0200, David E. Wheeler write:
> Following up from a suggestion from Tom Lane[1] to improve the
> documentation of boolean predicate JSON path expressions, please find
> enclosed a draft patch to do so.
Thanks for putting this together. See my review at the end.
> It does
On Oct 14, 2023, at 16:40, David E. Wheeler wrote:
> Following up from a suggestion from Tom Lane[1] to improve the documentation
> of boolean predicate JSON path expressions, please find enclosed a draft
> patch to do so.
And now I see I can’t spell “Deviations”. Will fix along with any
36 matches
Mail list logo
