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.