Am I missing anything, (ie memory leak, undesirable behavior elsewhere)?
-Ed
I applied the patch and it looks like it is working well. As a longtime
plpython user, I appreciate the fix.
I have a few comments:
1) I would remove the error message from the PO files as well.
2) You removed th
It sounds like there is interest in this feature, can it get added to
the TODO list?
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
On 04/26/2011 06:32 PM, Merlin Moncure wrote:
On Tue, Apr 26, 2011 at 9:24 AM, Robert Haas wrote:
On Tue, Apr 26, 2011 at 10:02 AM, David Fetter wrote:
On Tue, Apr 26, 2011 at 04:17:48PM +0300, Sim Zacks wrote:
On 04/26/2011 03:15 PM, Merlin Moncure wrote:
On Tue, Apr 26, 2011 at 3:28 AM
On 04/26/2011 04:22 PM, Stephen Frost wrote:
* Robert Haas (robertmh...@gmail.com) wrote:
On Tue, Apr 26, 2011 at 8:32 AM, Stephen Frost wrote:
Well, this specific thing could be done by just having PG close the
client connection, not care that it's gone, and have an implied
'commit;' at the
On 04/26/2011 03:32 PM, Stephen Frost wrote:
What I don't think we saw was any information about how, exactly, the OP
was planning to implement this in the backend.
Thanks,
Stephen
I'm at stage 1 of this proposal, meaning I know exactly what I want. I
am checking with
On 04/26/2011 03:15 PM, Merlin Moncure wrote:
On Tue, Apr 26, 2011 at 3:28 AM, Sim Zacks wrote:
Asynchronous functions
*Problem*
Postgresql does not have support for asynchronous function calls.
Well, there is asynchronous support from the client of course. Thus
you can set up a
statements ( CREATE TRIGGER ...
EXECUTE ASYNC trig_func() ). This should cause an internal session to be
started that the function or trigger function will run in, disconnected
from the session it started in.
Sim Zacks
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To