| commit | 22d0c30bd9662e48fb0d27253fec6a43c7673f13 | |
| author | Tom Lane <tgl@sss.pgh.pa.us> | |
| Wed, 19 Jul 2023 15:00:34 +0000 (19 11:00 -0400) | ||
| committer | Tom Lane <tgl@sss.pgh.pa.us> | |
| Wed, 19 Jul 2023 15:00:34 +0000 (19 11:00 -0400) | ||
| tree | 66c3b1d657b0023d69483e521b17c631778a03cd | treesnapshot (tar.gz zip) |
| parent | 04911fa767fda444c1a883a6ece32a0674cffd03 | commitdiff |
Doc: improve description of IN and row-constructor comparisons.
IN and NOT IN work fine on records and arrays, so just say that
they accept "expressions" not "scalar expressions". I think that
that phrasing was meant to say that they don't work on set-returning
expressions, but that's not the common meaning of "scalar".
Revise the description of row-constructor comparisons to make it
perhaps a bit less confusing. (This partially reverts some
dubious wording changes made by commit f56651519.)
Per gripe from Ilya Nenashev. Back-patch to supported branches.
In HEAD and v16, also drop a NOTE about pre-8.2 behavior, which
is hopefully no longer of interest to anybody.
Discussion: https://postgr.es/m/168968062460.632.14303906825812821399@wrigleys.postgresql.org
IN and NOT IN work fine on records and arrays, so just say that
they accept "expressions" not "scalar expressions". I think that
that phrasing was meant to say that they don't work on set-returning
expressions, but that's not the common meaning of "scalar".
Revise the description of row-constructor comparisons to make it
perhaps a bit less confusing. (This partially reverts some
dubious wording changes made by commit f56651519.)
Per gripe from Ilya Nenashev. Back-patch to supported branches.
In HEAD and v16, also drop a NOTE about pre-8.2 behavior, which
is hopefully no longer of interest to anybody.
Discussion: https://postgr.es/m/168968062460.632.14303906825812821399@wrigleys.postgresql.org
| doc/src/sgml/func.sgml | diffblobblamehistory |