Re: NEW.* and OLD.* inside trigger function don't seem to contain recently added columns

From: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
To: Janne Annala <janne(dot)annala(at)forenom(dot)com>
Cc: "pgsql-bugs(at)lists(dot)postgresql(dot)org" <pgsql-bugs(at)lists(dot)postgresql(dot)org>
Subject: Re: NEW.* and OLD.* inside trigger function don't seem to contain recently added columns
Date: 2024-03-23 00:41:52
Message-ID: 1218764.1711154512@sss.pgh.pa.us
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-bugs

Janne Annala <janne(dot)annala(at)forenom(dot)com> writes:
> Here's the minimum case to reproduce the issue:

> CREATE FUNCTION x()
> RETURNS trigger
> LANGUAGE plpgsql
> AS $function$
> BEGIN
> IF ROW(NEW.*) IS DISTINCT FROM ROW(OLD.*) THEN

Try dropping the ROW() bit, that is just

IF NEW.* IS DISTINCT FROM OLD.* THEN

or even

IF NEW IS DISTINCT FROM OLD THEN

I think what is happening is that the ROW() notation is getting
expanded at parse time to

ROW(NEW.id, NEW.old_column, NEW.updated)

and then there's no dependency on the original rowtype that would
lead to that expansion getting reconsidered. Arguably that's a
bug, but it's not clear to me what the consequences of changing
that behavior would be.

regards, tom lane

In response to

Responses

Browse pgsql-bugs by date

  From Date Subject
Next Message Peter Geoghegan 2024-03-23 02:24:52 Re: Index plan returns different results to sequential scan
Previous Message Alexander Korotkov 2024-03-23 00:39:36 Re: [BUG] false positive in bt_index_check in case of short 4B varlena datum