Re: BUG #18190: PL/pgSQL does not document comparison operations on RECORD (or ROW) types
David G. Johnston <david.g.johnston@gmail.com>
From: "David G. Johnston" <david.g.johnston@gmail.com>
To: "kop@karlpinc.com" <kop@karlpinc.com>, "pgsql-bugs@lists.postgresql.org" <pgsql-bugs@lists.postgresql.org>
Date: 2023-11-12T01:13:35Z
Lists: pgsql-bugs
On Friday, November 10, 2023, PG Bug reporting form <noreply@postgresql.org>
wrote:
> The following bug has been logged on the website:
>
> Bug reference: 18190
> Logged by: Karl Pinc
> Email address: kop@karlpinc.com
> PostgreSQL version: 15.4
> Operating system: Linux
> Description:
>
> Nothing is said about how to compare entire RECORD type variables, or ROW
> type variables.
There is, in the chapters with the word compare in their titles.
https://www.postgresql.org/docs/current/functions-comparison.html#FUNCTIONS-COMPARISON
https://www.postgresql.org/docs/current/functions-comparisons.html#FUNCTIONS-COMPARISONS
This leads to surprising behavior in the code below.
You couldn’t make something less difficult to read? Like a self-contained
select that shows true when you expected false? Or even a DO block with no
dynamic SQL?
IF problem IS NOT NULL THEN
As noted in the docs, “not (composite is null)” is not equivalent to
“composite is not null”; you usually want the former.
> If the issue is documentation, the PL/pgSQL docs should link to the
> composite type docs, or the expression docs, or type conversion, or where
> ever the current documentation is that I can't find or that needs to be
> written.
>
>
The behavior involved is in no way specific to pl/pgsql; it doesn’t seem
warranted to choose to link to SQL documentation from pl/pgsql generally.
The writer of such code can reference the SQL docs for any SQL they need to
write.
David J.