Tom Lane wrote:
Josh Berkus writes:
Summary: self-referential FKs are not enforced properly in the
presence of BEFORE triggers
This isn't a bug. If you create triggers that prevent the RI actions
from being taken, it's your own problem.
Huh? Since when was it OK by us to have data
Josh Berkus writes:
> Tom Lane wrote:
>> This isn't a bug. If you create triggers that prevent the RI actions
>> from being taken, it's your own problem.
> Huh? Since when was it OK by us to have data which violates a declared
> FK under *any* circumstances?
You can't have your cake and eat i
Josh Berkus writes:
> Summary: self-referential FKs are not enforced properly in the
> presence of BEFORE triggers
This isn't a bug. If you create triggers that prevent the RI actions
from being taken, it's your own problem.
regards, tom lane
--
Sent via pgsql-bu
Version: 8.3.5
Install: self-compile on 64-bit Ubuntu Linux
also reproduced by AndrewSN on another platform
Summary: self-referential FKs are not enforced properly in the
presence of BEFORE triggers
Test Case:
-- create two tables, one of which is the master table (reftable) the
I've progressed a bit farther on the dropped notification bug, which
amends my previous results.
I modified the error handling code for the kill() call in async.c to
check to see if the listenerPID is associated with a running backend
process. To do that, I call IsBackendPid(listenerPID). I
I found bug in tsearch2 module (8.3, 8.4).
Thank you, fixed
http://archives.postgresql.org/message-id/20090128183133.0d6f9755...@cvs.postgresql.org
(for 8.3 too)
--
Teodor Sigaev E-mail: teo...@sigaev.ru
WWW: h
"Marshall, Steve" writes:
> I don't think a check for process existance is a bad idea, or even a
> bandaid. The comment in the code block in async.c says it is removing
> the entry in pg_listener because the backend process does not exist.
In general, the way to see if a process exists is to try
The reason preserving the subscription is good is because the current
behavior silently drops the subscription without informing the
subscribing process in any way. This means applications waiting for
changes to a database tables have the mistaken impression no changes
have occurred.
The reason
"Marshall, Steve" writes:
> Essentially, the new error handling in async.c allows postgres to fail
> in its efforts to signal a process about the presence of a NOTIFY event
> without invalidating the subscription (LISTEN) for that event.
But why would that be a good idea? It seems to me to be a
Hello
I found bug in tsearch2 module (8.3, 8.4).
\i /usr/local/pgsql83/share/contrib/tsearch2.sql
create table t(d varchar, fi public.tsvector);
CREATE TRIGGER fux BEFORE INSERT OR UPDATE ON fulltexttest FOR EACH
ROW EXECUTE PROCEDURE tsearch2('fi', 'description');
postgres=# INSERT INTO fullte
10 matches
Mail list logo
