From: | Rafal Pietrak <rafal(at)zorro(dot)isa-geek(dot)com> |
---|---|
To: | Kenneth Downs <ken(at)secdat(dot)com> |
Cc: | Chris Browne <cbbrowne(at)acm(dot)org>, pgsql-general(at)postgresql(dot)org |
Subject: | Re: background triggers? |
Date: | 2006-05-24 12:29:51 |
Message-ID: | 1148473793.20217.128.camel@model.home.waw.pl |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-general |
On Wed, 2006-05-24 at 07:41 -0400, Kenneth Downs wrote:
> >
> Why not have the INSERT go to an "inbox" table, a table whose only job
> is to receive the data for future processing.
Actually, it 'sort of' works that way.
> Your client code should mark all rows with a batch number as they go
> in. Then when the batch is loaded, simply invoke a stored procedure to
> process them. Pass the stored procedure the batch number.
If I have that stored procedure and if I issue command that would launch
such stored procedure from "psql>" prompt: how long will I have to wait
for another prompt? 1) until the procedure ends its job. 2) right away,
the procedure does its job unabidedly 'in the background'.
My impression was, that I get the next prompt after the procedure
finishes, so it wouldn't be a solution. But if (2) applies, that is
really it.... Frankly, it would take me some time to get back to those
sources (and generate simulation data) - so anybody knows the answer?
-R
From | Date | Subject | |
---|---|---|---|
Next Message | Richard Huxton | 2006-05-24 12:32:34 | Re: compiling source code!!!!!!!!!!!!!!!!!!!!!!!!!!!!! |
Previous Message | Richard Huxton | 2006-05-24 12:26:57 | Re: Clearing out old idle connections |