> > 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 ---------------------------(end of broadcast)--------------------------- TIP 4: Don't 'kill -9' the postmaster
