Re: Dyamic updates of NEW with pl/pgsql

From: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
To: Merlin Moncure <mmoncure(at)gmail(dot)com>
Cc: Andrew Dunstan <andrew(at)dunslane(dot)net>, Pavel Stehule <pavel(dot)stehule(at)gmail(dot)com>, David Fetter <david(at)fetter(dot)org>, depesz(at)depesz(dot)com, pgsql-hackers(at)postgresql(dot)org
Subject: Re: Dyamic updates of NEW with pl/pgsql
Date: 2010-03-13 17:18:32
Message-ID: 3384.1268500712@sss.pgh.pa.us
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

Merlin Moncure <mmoncure(at)gmail(dot)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

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message David Fetter 2010-03-13 17:31:02 Re: Dyamic updates of NEW with pl/pgsql
Previous Message Tom Lane 2010-03-13 17:10:47 Re: pq_setkeepalives* functions