| From: | Merlin Moncure <mmoncure(at)gmail(dot)com> |
|---|---|
| To: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
| 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 16:55:45 |
| Message-ID: | b42b73151003130855n483ec843j64b9d7fa664c8935@mail.gmail.com |
| Views: | Raw Message | Whole Thread | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-hackers |
On Sat, Mar 13, 2010 at 11:40 AM, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)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
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Bruce Momjian | 2010-03-13 16:56:57 | Re: pq_setkeepalives* functions |
| Previous Message | Tom Lane | 2010-03-13 16:44:21 | Re: pq_setkeepalives* functions |