"Florian G. Pflug" <f...@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 -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers