Alvaro Herrera wrote:
It is a Postgres limitation as well. We _could_ make the server "really
start the transaction" at the point the first query is issued instead of
when the BEGIN is issued.
And also, really finish the transaction right after the last
statement is executed, instead of waiting u
Andrew Sullivan wrote:
On Tue, Apr 12, 2005 at 10:55:30AM -0400, Carlos Moreno wrote:
I guess the concern came up as result of a particular
situation, in which failing to properly process the
trigger function is not that crucial (I wanted to
update some additional information that is "opt
Richard Huxton wrote:
I just noticed this (odd?) behaviour, and it kind of
scares me.
Isn't this a little fragile? Is there something I
could do to avoid this situation? Should trigger
functions be extremely simple as to guarantee that
an error would never happen?
There's nothing else it can do,
Hi,
I just noticed this (odd?) behaviour, and it kind of
scares me.
For testing purposes, I put a deliberate syntax error;
this wouldn't happen in a real-life situation. But what
if the error gets triggered by something that happens
later on? say, if the trigger function uses a field
that later o
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 bee
Hello,
A question from a complete newbie on this area.
I'm trying to implement a mechanism that would allow me to
keep track of the last time each row of a table was modified.
I have many applications modifying the data, and I would
like to avoid having to modify each of those applications
(with th
