Re: transition tables and UPDATE

> > > even uglier than what I already had. So yeah, I think it might be > useful if we had a way to inject a counter or something in there. > > This came up for me when I was experimenting with making the referential integrity triggers fire on statements rather than rows. Doing so has the

Re: transition tables and UPDATE

On Wed, 1 Feb 2023 10:03:26 +0100 Alvaro Herrera wrote: > Earlier today I gave a talk about MERGE and wanted to provide an example > with FOR EACH STATEMENT triggers using transition tables. However, I > can't find a non-ugly way to obtain the NEW row that corresponds to each > OLD row ... I

Re: transition tables and UPDATE

On Wed, 1 Feb 2023 at 12:12, Alvaro Herrera wrote: > > I had tried to tie these relations using WITH ORDINALITY, but the only > way I could think of (array_agg to then unnest() WITH ORDINALITY) was > even uglier than what I already had. So yeah, I think it might be > useful if we had a way to

Re: transition tables and UPDATE

On 2023-Feb-01, Thomas Munro wrote: > On Wed, Feb 1, 2023 at 10:18 PM Alvaro Herrera > wrote: > > Earlier today I gave a talk about MERGE and wanted to provide an example > > with FOR EACH STATEMENT triggers using transition tables. However, I > > can't find a non-ugly way to obtain the NEW

Re: transition tables and UPDATE

On Wed, Feb 1, 2023 at 10:18 PM Alvaro Herrera wrote: > Earlier today I gave a talk about MERGE and wanted to provide an example > with FOR EACH STATEMENT triggers using transition tables. However, I > can't find a non-ugly way to obtain the NEW row that corresponds to each > OLD row ... I had

transition tables and UPDATE

Earlier today I gave a talk about MERGE and wanted to provide an example with FOR EACH STATEMENT triggers using transition tables. However, I can't find a non-ugly way to obtain the NEW row that corresponds to each OLD row ... I had to resort to an ugly trick with OFFSET n LIMIT 1. Can anyone

Re: Unexpected behavior with transition tables in update statement trigger

On Wed, Feb 28, 2018 at 10:27:23AM +1300, Thomas Munro wrote: Tom K, if you need a workaround before 10.4 comes out in May[1], you could try selecting the whole transition table into a CTE up front. Something like WITH my_copy AS (SELECT * FROM new_table) SELECT * FROM my_copy UNION ALL SELECT *

Re: Unexpected behavior with transition tables in update statement trigger

On Tue, Feb 27, 2018 at 03:58:14PM -0500, Tom Lane wrote: Thomas Munro writes: Here's a new version with tuplestore_select_read_pointer() added in another place where it was lacking, and commit message. Moving to -hackers, where patches go. Pushed, along with

Re: Unexpected behavior with transition tables in update statement trigger

On Wed, Feb 28, 2018 at 9:58 AM, Tom Lane wrote: > Thomas Munro writes: >> Here's a new version with tuplestore_select_read_pointer() added in >> another place where it was lacking, and commit message. Moving to >> -hackers, where patches go. >

Re: Unexpected behavior with transition tables in update statement trigger

Thomas Munro writes: > Here's a new version with tuplestore_select_read_pointer() added in > another place where it was lacking, and commit message. Moving to > -hackers, where patches go. Pushed, along with a regression test based on your example. Unfortunately,

Re: Unexpected behavior with transition tables in update statement trigger

On Tue, Feb 27, 2018 at 02:52:02PM +1300, Thomas Munro wrote: On Tue, Feb 27, 2018 at 4:18 AM, Tom Kazimiers wrote: It would be great if this or a similar fix would make it into the next official release. Here's a new version with tuplestore_select_read_pointer() added

Re: Unexpected behavior with transition tables in update statement trigger

On Tue, Feb 27, 2018 at 4:18 AM, Tom Kazimiers wrote: > On Mon, Feb 26, 2018 at 11:15:44PM +1300, Thomas Munro wrote: >> On Sat, Feb 24, 2018 at 4:47 PM, Tom Kazimiers >> wrote: >> Thanks for the reproducer. Yeah, that seems to be a bug. >>