From: | Hannu Krosing <hannu(at)skype(dot)net> |
---|---|
To: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
Cc: | "Jonah H(dot) Harris" <jonah(dot)harris(at)gmail(dot)com>, Lane Van Ingen <lvaningen(at)esncc(dot)com>, pgsql-hackers(at)postgresql(dot)org |
Subject: | Re: Need A Suggestion |
Date: | 2005-10-11 10:14:26 |
Message-ID: | 1129025666.4851.1.camel@fuji.krosing.net |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
On E, 2005-10-10 at 16:32 -0400, Tom Lane wrote:
> "Jonah H. Harris" <jonah(dot)harris(at)gmail(dot)com> writes:
> > In the past, I've just written a C-based function that calls out to system.
>
> Use pltclu, plpythonu, or plperlu, according to taste. They all have
> pre-existing solutions for this.
>
> Whether this is a good idea is another question entirely. Lots of
> people will tell you it's a horrid idea for PG functions to cause
> outside-the-database side effects. The reason is that if the
> transaction that called the function aborts later, there is no way
> to roll back what was done outside the database, and so the state
> outside the database will no longer be in sync with the state inside.
Is there a simple, user-accessible mechanism to schedule a function to
be run at query commit ?
--
Hannu Krosing <hannu(at)skype(dot)net>
From | Date | Subject | |
---|---|---|---|
Next Message | Ilia Kantor | 2005-10-11 10:23:02 | Re: slow IN() clause for many cases |
Previous Message | Simon Riggs | 2005-10-11 09:58:58 | Re: slower merge join on sorted data chosen over |