Re: comparing NEW and OLD (any good this way?)

From: "Daniel Verite" <daniel(at)manitou-mail(dot)org>
To: pgsql-general(at)postgresql(dot)org
Subject: Re: comparing NEW and OLD (any good this way?)
Date: 2009-08-12 20:57:54
Message-ID: e7188e46-53f7-4b22-9ba7-a6c36a066c9c@mm
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: 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

In response to

Responses

Browse pgsql-general by date

  From Date Subject
Next Message Emanuel Calvo Franco 2009-08-12 21:46:02 Simulate count result are distinct between 8.3 and 8.4
Previous Message Andy Colson 2009-08-12 19:40:51 Re: synchronous_commit and mvcc