Re: SQL:2011 application time - Mailing list pgsql-hackers

From Paul Jungwirth
Subject Re: SQL:2011 application time
Date
Msg-id 34f9c43a-bad0-482a-a563-a3c202a2b678@illuminatedcomputing.com
Whole thread Raw
In response to Re: SQL:2011 application time  (Peter Eisentraut <peter@eisentraut.org>)
List pgsql-hackers
Here is another set of patches, just rebasing and fixing a CI failure in contrib/sepgsql.

On 3/10/25 03:56, Peter Eisentraut wrote:
 > I think this is about as much as we can hope to get done from this patch series for PG18.  I don't
 > think the subsequent patches are ready enough.  As an example, the FOR PORTION OF still has the
 > problem I mentioned at <https://www.postgresql.org/message-id/d4c5de4d-ff2d-4ef6-
 > b7a2-1787dfa6427b%40eisentraut.org>, and a few similar structural problems.

I agree that UPDATE/DELETE FOR PORTION OF is a lot to add this late in the cycle. Can you say more 
about the problems at that link though? The change you asked for has been in the patches since v45.

There is something similar happening for the range constructor, so maybe that's what you're seeing 
now? But in that case we don't have prior oid access. Looking up the function by range type name and 
arg count/type is the only way to get it. I guess I don't have to use makeFuncCall and 
transformExpr, but since I *do* need to call transformExpr on the FROM and TO inputs, it seems 
simplest to do it all together.

 > Also, I see that you
 > have recently changed some things to make use of SPI, which seems problematic.  This needs much
 > further analysis.

Okay, when you have time please let me know more about this. Using SPI fixed a lot of issues around 
firing triggers on the leftover inserts, as well as tuple routing for partitioned tables. For 
details see 
https://www.postgresql.org/message-id/CA%2BrenyUFC13F0tYKxEENZtWA0YVuS5Tv%2BZQkEkAwuDO1-Xke-A%40mail.gmail.com 
I thought since we use SPI for foreign keys, it should be safe to use it here as well.

 > My suggestions is to close the commitfest entry as "committed" and start new threads and new entries
 > for the subsequent features.

Vignesh closed the current commitfest entry already, but I'll make a new one. The patches mostly 
depend on each other, so I'll make just one.

Rebased to 5941946d09.

Yours,

-- 
Paul              ~{:-)
pj@illuminatedcomputing.com

Attachment

pgsql-hackers by date:

Previous
From: Amit Kapila
Date:
Subject: Re: Separate GUC for replication origins
Next
From: Paul Jungwirth
Date:
Subject: Re: SQL:2011 application time