Re: Dyamic updates of NEW with pl/pgsql

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

In response to

Browse pgsql-hackers by date

  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