On 28 June 2013 17:17, Tom Lane wrote:
> Simon Riggs writes:
> > We claim conformance to the standard on this.
>
> Not really. The fact that we do RI actions via triggers is already not
> what the spec envisions. As an example, it's well known that you can
> subvert RI actions entirely by inst
Simon Riggs writes:
> We claim conformance to the standard on this.
Not really. The fact that we do RI actions via triggers is already not
what the spec envisions. As an example, it's well known that you can
subvert RI actions entirely by installing triggers on the target table
that make the RI
On 28 June 2013 16:09, David Greco wrote:
> Yes, renaming the trigger does in fact work. Any thoughts on the theory of
> this behavior? i.e. is this ANSI compliant? Or should there be a mechanism
> in place that guarantees the FK-enforcement trigger runs after all others?
>
Hmm, it doesn't conf
-Original Message-
From: Tom Lane [mailto:t...@sss.pgh.pa.us]
Sent: Friday, June 28, 2013 10:10 AM
To: David Greco
Cc: pgsql-general@postgresql.org
Subject: Re: [GENERAL] AFTER triggers and constraints
David Greco writes:
> Since the trigger is defined as AFTER ROW, versus AF
David Greco writes:
> Since the trigger is defined as AFTER ROW, versus AFTER STATEMENT, I believe
> the trigger should be considered part of the statement, therefore the
> constraint should not be checked until after the row triggers have run. Any
> thoughts?
Not sure that this is terribly we
From: Vick Khera [mailto:vi...@khera.org]
Sent: Friday, June 28, 2013 9:35 AM
To: David Greco
Cc: pgsql-general@postgresql.org
Subject: Re: [GENERAL] AFTER triggers and constraints
On Fri, Jun 28, 2013 at 8:45 AM, David Greco
mailto:david_gr...@harte-hanks.com>> wrote:
The last delete sta
On Fri, Jun 28, 2013 at 8:45 AM, David Greco wrote:
> The last delete statement will throw a referential integrity error. In
> Oracle, same example, it does not as the trigger deletes the child.
>
>
Not sure your real case, but why not just make the FK on delete cascade and
get rid of your tri
Came across an interesting situation as part of our Oracle to PostgreSQL
migration. In Oracle, it appears that immediate constraints are checked after
the entire statement is run, including any AFTER ROW triggers. In Postgres,
they are applied before the AFTER ROW triggers. In some of our AFTER
