| From: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
|---|---|
| To: | Adrian Klaver <adrian(dot)klaver(at)aklaver(dot)com> |
| Cc: | Brian Mendoza <brian(at)rotamap(dot)net>, pgsql-general(at)postgresql(dot)org |
| Subject: | Re: JSONB operator unanticipated behaviour |
| Date: | 2023-05-18 16:36:41 |
| Message-ID: | 3853945.1684427801@sss.pgh.pa.us |
| Views: | Raw Message | Whole Thread | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-general |
Adrian Klaver <adrian(dot)klaver(at)aklaver(dot)com> writes:
> On 5/18/23 08:46, Tom Lane wrote:
>> You seem to be reading some fairly old version of the documentation.
>> The extended definition that Adrian mentions has been there for
>> awhile, but the JSON operator table didn't link to it before v13.
>> (I agree that the "top level" bit was just wrong, but it's gone.)
> Can you elaborate on gone and/or wrong as I see it in the 15 and devel
> documentation.
In v12 (and probably earlier, didn't look) Table 9.45 defines @> as
"Does the left JSON value contain the right JSON path/value entries
at the top level?" [1].
regards, tom lane
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Tony Xu | 2023-05-18 17:00:42 | Re: Would PostgreSQL 16 native transparent data encryption support database level encryption? |
| Previous Message | Owen Stephens | 2023-05-18 16:34:27 | Unexpected cross-database vacuum impact with hot_standby_feedback=on |