From: | Josh Kupershmidt <schmiddy(at)gmail(dot)com> |
---|---|
To: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
Cc: | Pavel Stehule <pavel(dot)stehule(at)gmail(dot)com>, pgsql-docs <pgsql-docs(at)postgresql(dot)org> |
Subject: | Re: [BUGS] documentation bug - behave of NEW a OLD in plpgsql's triggers |
Date: | 2011-05-06 02:58:24 |
Message-ID: | BANLkTin=Z+JZLwXKOnNmxcDKt2aXr8p4vg@mail.gmail.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-bugs pgsql-docs |
On Thu, May 5, 2011 at 10:36 PM, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> wrote:
> That is, in fact, exactly the behavior you get if you declare a RECORD
> variable and set it to NULL. If these variables were indeed not
> declared, you'd get a complaint about "new" not being a known variable.
Hrm, guess I learned something. I tested with a trigger function which used:
...
IF NEW IS NULL THEN
RAISE NOTICE 'new is null.';
...
which was giving me 'ERROR: record "new" is not assigned yet' when
used as an on-delete trigger. I am a little surprised that you can't
use IS NULL to test out a record-type variable which you've just
declared to be NULL, e.g. this function blows up:
CREATE OR REPLACE FUNCTION test_trg() RETURNS TRIGGER AS $$
DECLARE SOMEVAR record;
BEGIN
SOMEVAR := NULL;
IF SOMEVAR IS NULL THEN
RAISE NOTICE 'somevar is null.';
END IF;
RETURN NEW;
END;
$$ LANGUAGE plpgsql;
with the same error message.
Josh
From | Date | Subject | |
---|---|---|---|
Next Message | Tom Lane | 2011-05-06 03:32:54 | Re: [BUGS] documentation bug - behave of NEW a OLD in plpgsql's triggers |
Previous Message | Tom Lane | 2011-05-06 02:36:35 | Re: [BUGS] documentation bug - behave of NEW a OLD in plpgsql's triggers |
From | Date | Subject | |
---|---|---|---|
Next Message | Tom Lane | 2011-05-06 03:32:54 | Re: [BUGS] documentation bug - behave of NEW a OLD in plpgsql's triggers |
Previous Message | Tom Lane | 2011-05-06 02:36:35 | Re: [BUGS] documentation bug - behave of NEW a OLD in plpgsql's triggers |