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.

which is not too friendly, given that people sometimes forget to specify
FOR EACH <sth> at all, get the default behaviour of FOR EACH STATEMENT
and scratch their heads. A quick search on the error detail reveals a
few such confused users already.

What's more, the documentation for PL/pgSQL triggers says that "This
variable is NULL in statement-level triggers" but it's not really a
NULL, for instance you can't execute "x is NULL" with it (you get the
same error).

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.

Would that make sense?

Cheers,
Jan

PS: If changing them to row types would induce too much code churn that
maybe we could use some trick to check if the error comes from using the
OLD or NEW variable and add a HINT to the error message?

J

Search Discussions

  • Tom Lane at Jan 28, 2012 at 11:21 pm

    =?UTF-8?B?SmFuIFVyYmHFhHNraQ==?= <wulczer@wulczer.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

Related Discussions

Discussion Navigation
viewthread | post
Discussion Overview
grouppgsql-hackers @
categoriespostgresql
postedJan 28, '12 at 11:01p
activeJan 28, '12 at 11:21p
posts2
users2
websitepostgresql.org...
irc#postgresql

2 users in discussion

Tom Lane: 1 post Jan Urbański: 1 post

People

Translate

site design / logo © 2021 Grokbase