Re: comparing NEW and OLD (any good this way?) - Mailing list pgsql-general

From Daniel Verite
Subject Re: comparing NEW and OLD (any good this way?)
Date
Msg-id e7188e46-53f7-4b22-9ba7-a6c36a066c9c@mm
Whole thread Raw
In response to Re: comparing NEW and OLD (any good this way?)  (Sam Mason <sam@samason.me.uk>)
Responses Re: comparing NEW and OLD (any good this way?)
List pgsql-general
    Sam Mason wrote:

> > But for rows, there is no such thing. You can't assign null to a row, it
> > makes no sense and actually causes an error.
>
> What makes you say this?  There's no reason I can see that would cause
> row values should be special in this way.  Maybe if you could define
> what you mean by "you can't assign null to a row"?

It seems to me that there is something special with rows: in tables, the
values of columns may be null or not, but at the level of the row, there is
no information that would say: this row itself as an object is null.

Anyway, let's try to assign null to a row variable (with 8.4.0):

CREATE TABLE our_table(i int);

CREATE FUNCTION test() returns void as $$
declare
 r our_table;
begin
 r:=null;
end;
$$ LANGUAGE plpgsql;

SELECT test() yields:
ERROR:    cannot assign non-composite value to a row variable
CONTEXT:  PL/pgSQL function "test" line 4 at assignment

As a follow-up to the comparison between rows and arrays, note that if we'd
make r an int[],  there would be no error.

However, I agree that if we consider that a row is a composite type, then
there is a problem because we sure can insert NULL into a column that is of a
composite type. So the "row cannot be null" line of reasoning holds only so
far as you don't stuff rows into columns :)

Best regards,
--
Daniel
PostgreSQL-powered mail user agent and storage: http://www.manitou-mail.org

pgsql-general by date:

Previous
From: Andy Colson
Date:
Subject: Re: synchronous_commit and mvcc
Next
From: Emanuel Calvo Franco
Date:
Subject: Simulate count result are distinct between 8.3 and 8.4