Re: SQL:2011 application time

On 12/10/24 06:40, Peter Eisentraut wrote:
> On 07.12.24 20:29, Paul Jungwirth wrote:
>> These five patches all look good to me.
>>
>> Note that my tests already include a section for REPLICA IDENTITY FULL, which passed. But the
>> subscriber was using a SeqScan to look up tuples to update.
>>
>> Here are the steps (mostly just because it was confusing for me at first): First in
>> FindUsableIndexForReplicaIdentityFull, we would call IsIndexUsableForReplicaIdentityFull, get back
>> false, and decide there was no index to use. Then in FindReplTupleInLocalRel, localidxoid was 0,
>> so we woudln't call IsIndexUsableForReplicaIdentityFull at all.
>>
>> After applying the five patches, I can see that we choose the index and call
>> IsIndexUsableForReplicaIdentityFull from both sites. This should make applying changes a lot faster.
>
> I have committed these.  I will continue with reviewing v45-0002 and following now.

Here is a rebase for the remaining patches. There are some small changes, but almost all the work
was fixing the final PERIOD patch (mostly to work with the new cataloged NOT NULL code).

The most important patches are the first two, since they fix bugs in the already-committed FK code.

I'd love to see FOR PORTION OF get into v18 also, but I'm not sure how much work remains there. It
don't think I've received feedback from a committer yet. It felt ready to commit to me, but after
the FK fixes here I don't like how I'm getting both an operator and a proc for intersection, in
different places. It seems like I should be able to make do with just one in all places. But since
intersect is neither a search operator nor an ordering operator, it can't appear in pg_amop, so you
can't look it up by stratnum. Maybe the intersect support func should return an operator oid, not a
proc oid, and then I can use pg_operator.oprcode to call its proc directly. If that sounds good I'll
make the changes.

Rebased to e28033fe1a.

--
Paul ~{:-)
pj(at)illuminatedcomputing(dot)com