| From: | David Fetter <david(at)fetter(dot)org> |
|---|---|
| To: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
| Cc: | Merlin Moncure <mmoncure(at)gmail(dot)com>, Andrew Dunstan <andrew(at)dunslane(dot)net>, Pavel Stehule <pavel(dot)stehule(at)gmail(dot)com>, 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:02 |
| Message-ID: | 20100313173102.GN15080@fetter.org |
| Views: | Whole Thread | Raw Message | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-hackers |
On Sat, Mar 13, 2010 at 12:18:32PM -0500, Tom Lane wrote:
> 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.
Yes. Well, at least the same base type. I don't suppose now is a
great time to get into the second class status of domains. :P
Cheers,
David.
--
David Fetter <david(at)fetter(dot)org> http://fetter.org/
Phone: +1 415 235 3778 AIM: dfetter666 Yahoo!: dfetter
Skype: davidfetter XMPP: david(dot)fetter(at)gmail(dot)com
iCal: webcal://www.tripit.com/feed/ical/people/david74/tripit.ics
Remember to vote!
Consider donating to Postgres: http://www.postgresql.org/about/donate
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Andrew Dunstan | 2010-03-13 17:31:59 | Re: Dyamic updates of NEW with pl/pgsql |
| Previous Message | Tom Lane | 2010-03-13 17:18:32 | Re: Dyamic updates of NEW with pl/pgsql |