Re: proposal - plpgsql - all plpgsql auto variables should be constant - Mailing list pgsql-hackers

On Fri, 24 Apr 2020 at 10:08, Tom Lane <tgl@sss.pgh.pa.us> wrote:
>
> I'm skeptical.  If we'd marked them that way from day one, it would have
> been fine, but to change it now is a whole different discussion.  I think
> the odds that anybody will thank us are much smaller than the odds that
> there will be complaints.  In particular, I'd be just about certain that
> there are people out there who are changing FOUND and loop control
> variables manually, and they will not appreciate us breaking their code.

I kind of doubt it would break anybody's code. But I also doubt it's
actually going to help anybody. It's not exactly an easy bug to write,
so meh, I can't really get worked up either way about this.

> As for the trigger variables specifically, what is the rationale
> for marking TG_OP read-only but not OLD and NEW?  But it is dead
> certain that we won't get away with making the latter two read-only.

But, uh, this actually seems like it might help people. Obviously we
can't make NEW constant for BEFORE triggers, but for AFTER triggers it
would actually be catching quite an easy-to-write bug. I bet plenty of
people accidentally define triggers as AFTER triggers which are
intending to modify the columns being stored and then don't understand
why they aren't working.

They might not even find out right away if the trigger only modifies
the columns sometimes so it could be the kind of latent bug that
catches people in production (which wouldn't be improved by the patch
but at least it would produce an error rather than silent data
corruption).

The only valid use cases that maybe would cause some pain would be
people using the same function for BEFORE *and* AFTER triggers and
where that code is written to just assign to NEW in both cases. That
seems like it would be odd though since we're not talking about an
audit function or something like that if the function is assigning to
NEW...

--
greg