I think I sent my previous message to John only (sorry!)
I just wanted to double check one detail that is not explicitly
stated in the documentation for createlang.
My question is: can I use createlang on a database that is
currently active? That is, a database with plenty of tables
that has
On Apr 7, 2005, at 5:45 PM, Carlos Moreno wrote:
The thing seems to work -- I had to go in a shell as user
postgres and execute the command:
$ createlang -d dbname plpgsql
(I'm not sure I understand why that is necessary, or
what implications -- positive or negative -- it may have)
As a security
On Apr 8, 2005, at 8:28 AM, John DeSoi wrote:
On Apr 7, 2005, at 5:45 PM, Carlos Moreno wrote:
The thing seems to work -- I had to go in a shell as user
postgres and execute the command:
$ createlang -d dbname plpgsql
(I'm not sure I understand why that is necessary, or
what implications --
On Apr 8, 2005, at 9:41 AM, Sean Davis wrote:
Just one detail, but in the form of a question. In the original
posting, I think the trigger was doing the logging for something
happening on a table as a before insert or update--I may be wrong on
that detail. I would think of doing such actions
Sean Davis [EMAIL PROTECTED] writes:
Just one detail, but in the form of a question. In the original
posting, I think the trigger was doing the logging for something
happening on a table as a before insert or update--I may be wrong on
that detail. I would think of doing such actions AFTER
On Fri, Apr 08, 2005 at 10:36:26AM -0400, Tom Lane wrote:
AFAICS the only way that you could get into a can't-roll-back situation
is if the trigger tries to propagate the update outside the database.
For instance, the proverbial trigger to send mail: once sent you can't
cancel it. But really
Andrew Sullivan [EMAIL PROTECTED] writes:
On Fri, Apr 08, 2005 at 10:36:26AM -0400, Tom Lane wrote:
AFAICS the only way that you could get into a can't-roll-back situation
is if the trigger tries to propagate the update outside the database.
For instance, the proverbial trigger to send mail:
Tom,
Thanks for setting the record straight. It has been a while since I
have written a trigger and I forgot that you can't modify the row in
the AFTER trigger. Makes perfect sense.
For the record, here is what the docs say:
Typically, row before triggers are used for checking or modifying the
On Fri, Apr 08, 2005 at 11:35:47AM -0400, Tom Lane wrote:
What this does do for you is replace the risk of phantom emails (mail
sent but corresponding action inside the database never committed)
with the risk of duplicate emails (mail-sender sends you another one
after it restarts). In most
Tom Lane wrote:
The hypothetical mail-sending process
would presumably want to send mail and then delete the associated record
from the table of pending mails ... so what if it fails after sending
the mail and before committing the delete?
What this does do for you is replace the risk of phantom
On Apr 8, 2005, at 10:59 AM, Andrew Sullivan wrote:
wakes up the mail-sender client with the NOTIFY; the NOTIFY and the
commit to the mail-it table only happen in that case if the
transaction commits. And since mail is async anyway, the extra few
seconds shouldn't make any difference, right?
I
Vivek Khera [EMAIL PROTECTED] writes:
I have a lot of processing that could benefit from this type of
synchronization, except the fact that there's no Pg command to wait
until I get a notify message.
This is a client library deficiency, not a problem with the backend or
the protocol. In
12 matches
Mail list logo
