From: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
---|---|
To: | Jan Urbański <wulczer(at)wulczer(dot)org> |
Cc: | Postgres - Hackers <pgsql-hackers(at)postgresql(dot)org> |
Subject: | Re: unfriendly error when accessing NEW in statement-level trigger |
Date: | 2012-01-28 23:20:56 |
Message-ID: | 5519.1327792856@sss.pgh.pa.us |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
=?UTF-8?B?SmFuIFVyYmHFhHNraQ==?= <wulczer(at)wulczer(dot)org> writes:
> When you try to use the NEW variable in a statement-level trigger, you get
> ERROR: record "new" is not assigned yet
> DETAIL: The tuple structure of a not-yet-assigned record is indeterminate.
> I'm not that familiar with PL/pgSQL code, so I'm not sure how or if this
> should be fixed. From a quick look it seems that the NEW and OLD
> variables could be defined as row variables instead of record, since the
> format of the tuple is known.
Yeah, maybe. I suspect that that wouldn't have worked when the code was
first designed, but now that we create a separate execution context for
each trigger target table, it should be the case that NEW/OLD have
stable structure. You'd need to watch out for ALTER TABLE commands
though --- I don't remember exactly what plpgql does about rowtypes
changing underneath it.
regards, tom lane
From | Date | Subject | |
---|---|---|---|
Next Message | Jeff Janes | 2012-01-29 00:48:53 | Re: Group commit, revised |
Previous Message | Tom Lane | 2012-01-28 23:05:41 | Re: Second thoughts on CheckIndexCompatible() vs. operator families |