Re: [BUGS] BUG #14808: V10-beta4, backend abort - Mailing list pgsql-bugs

From Thomas Munro
Subject Re: [BUGS] BUG #14808: V10-beta4, backend abort
Date
Msg-id CAEepm=015ZFuo2AEFF+maS2AvL7PGkdZ_=uUErpPXzNm3TbGWQ@mail.gmail.com
Whole thread Raw
In response to Re: [BUGS] BUG #14808: V10-beta4, backend abort  (Tom Lane <tgl@sss.pgh.pa.us>)
Responses Re: [BUGS] BUG #14808: V10-beta4, backend abort
List pgsql-bugs
On Tue, Sep 12, 2017 at 12:53 PM, Tom Lane <tgl@sss.pgh.pa.us> wrote:
> OTOH, looking at the text of
> the spec, I think it's darn hard to justify the behavior shown above.

Yeah.  I assume we always fired statement triggers for each separate
instance of the same table mentioned in a wCTE since they were
invented.  I just confirmed that that is the case in 9.6.  That may
not have been in the spirit of the spec, but it's hard to say because
the spec doesn't have wCTEs IIUC and it mattered less because they
didn't receive any data.

Now that they can optionally see data resulting from modifications, it
seems pretty hard to use this feature to build anything that consumes
the transition data and has to be reliable (matview state,
replication-like systems etc) if we make any choice other than (1)
each instance of a given table fires a statement trigger separately
and sees only the rows it touched, or (2) the statement trigger is
fired once for all instances of a table, and sees all the transition
tuples.  Based on the SQL spec excerpts you've highlighted, I suppose
it seems likely that if the spec had wCTEs it would expect them to
work like (2).

-- 
Thomas Munro
http://www.enterprisedb.com


-- 
Sent via pgsql-bugs mailing list (pgsql-bugs@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-bugs

pgsql-bugs by date:

Previous
From: Tom Lane
Date:
Subject: Re: [BUGS] BUG #14808: V10-beta4, backend abort
Next
From: Oleg Serov
Date:
Subject: Re: [BUGS] BUG #14811: Nested IN SUBQERY that returns empty resultsexecuted multiple times.