Merlin Moncure <mmoncure@gmail.com> writes:
> ... It just doesn't seem right that you should have to
> write N trigger functions over N tables to a highly related
> operations. pl/perl is a huge dependency to bring in just to able to
> do things this. I understand hacking things through the text route is
> possibly not a direction should be encouraged...but is there an
> alternative? Is it theoretically possible to write functions that can
> switch out types based on context while still having static plans?
[ after a little bit of reflection ]
ISTM that in most cases where this is a serious issue, the trigger
functions are doing the *same* thing to different tables. Not just
textually the same, but datatype-wise the same. So I'm not sure I
believe that we need to be able to "switch out types". Maybe it would
work to devise a notation that allows fetching or storing a field that
has a runtime-determined name, but prespecifies the field type.
Actually only the "fetch" end of it is an issue, since when storing the
field datatype can be inferred from the expression you're trying to
assign to the field.
regards, tom lane
