"Florian G. Pflug" <fgp@phlo.org> writes:
> Tom Lane wrote:
>> Perhaps it would help if we looked at some specific use-cases that
>> people need, rather than debating abstractly. What do you need your
>> generic trigger to *do*?
> I need to build a global index table of all values of a certain type
> together with a pointer to the row and table that contains them. Since
> all involved tables have an "id" column, storing that pointer is the
> easy part. The hard part is collecting all those values in an
> insert/update/delete trigger so that I can update the global index
> accordingly.
So in this case it seems like you don't actually need any polymorphism
at all; the target columns are always of a known datatype. You just
don't want to commit to their names. I wonder though why you're willing
to pin down the name of the "id" column but not the name of the data
column.
> Currently, a set of plpgsql functions generate a seperate trigger
> function for each table. Yuck!
Would you be happy with an approach similar to what Andrew mentioned,
ie, you generate CREATE TRIGGER commands that list the names of the
target column(s) as TG_ARGV arguments? The alternative to that seems
to be that you iterate at runtime through all the table columns to
see which ones are of the desired type. Which might be less trouble
to set up, but the performance penalty of figuring out
basically-unchanging information again on every single tuple update
seems awful high.
regards, tom lane
