From: | Andrew Dunstan <andrew(at)dunslane(dot)net> |
---|---|
To: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
Cc: | Merlin Moncure <mmoncure(at)gmail(dot)com>, 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:31:59 |
Message-ID: | 4B9BCC0F.7090308@dunslane.net |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
Tom Lane wrote:
>
> 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.
>
>
>
That's exactly the sort of thing I had in mind. I wasn't talking about
loosening the type system. Classic case: you want to set/update a
timestamp field in the NEW record, but it might not be called the same
thing on each table, so you pass the field name as a trigger argument.
cheers
andrew
From | Date | Subject | |
---|---|---|---|
Next Message | Tom Lane | 2010-03-13 17:38:08 | Re: Dyamic updates of NEW with pl/pgsql |
Previous Message | David Fetter | 2010-03-13 17:31:02 | Re: Dyamic updates of NEW with pl/pgsql |