Re: patch: plpgsql - access records with rec.(expr)

> > See your point. But what about NEW.($1)?
>
> I don't follow -- what do you mean?

I want to be able to be able to write a trigger function that accesses a
column passed as an argument to the function in the row that caused the
trigger. This is my use case.

I guess that would actually written NEW.(TG_ARGV[1]).

> (BTW, I think my comment also applies to variables of type "text" and
> similar -- I think the patch would be a lot simpler if you just
> implement access to record fields by ordinal position, and don't
> implement access by field name.)

Yes, it would be marginally simpler: I'd still have to call
exec_eval_datum() on the variable and check whether it could be
evaluated to an integer (trigger args are all text AFAIK). The only
difference would be throwing an error if it wasn't, instead of making
use of the value... and a slightly less readable 'create trigger'
statement.

It would be a good idea to check that the variable was either a constant
or a trigger arg. This would stop the looping problem, since the type of
the underlying field couldn't change.

But I've somehow got the feeling that this sort of thing isn't the
issue. The issue is whether we want to allow dynamic access to columns
in any syntax at all. A simple yes or no would do :)

Matt

BTW: here's the original post adding the rec.(3) syntax to the TODO:
http://archives.postgresql.org/pgsql-hackers/2003-07/msg00425.php
here's someone else who tried something very similar:
http://archives.postgresql.org/pgsql-hackers/2003-09/msg00533.php