Re: Dyamic updates of NEW with pl/pgsql - Mailing list pgsql-hackers

From Merlin Moncure
Subject Re: Dyamic updates of NEW with pl/pgsql
Date
Msg-id b42b73151003130855n483ec843j64b9d7fa664c8935@mail.gmail.com
Whole thread Raw
In response to Re: Dyamic updates of NEW with pl/pgsql  (Tom Lane <tgl@sss.pgh.pa.us>)
Responses Re: Dyamic updates of NEW with pl/pgsql
Re: Dyamic updates of NEW with pl/pgsql
List pgsql-hackers
On Sat, Mar 13, 2010 at 11:40 AM, Tom Lane <tgl@sss.pgh.pa.us> wrote:
> (This will also be my main objection to letting hstore into core.
> It has not solved the problem of handling real datatypes.)

Is this problem solvable then? Some variant of this question comes up
almost weekly.  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?

merlin


pgsql-hackers by date:

Previous
From: Tom Lane
Date:
Subject: Re: pq_setkeepalives* functions
Next
From: Bruce Momjian
Date:
Subject: Re: pq_setkeepalives* functions