Horton

Re: SQL:2011 application time

Paul A Jungwirth <pj@illuminatedcomputing.com>

View thread
From: Paul Jungwirth <pj@illuminatedcomputing.com>
To: Peter Eisentraut <peter@eisentraut.org>
Cc: jian he <jian.universality@gmail.com>, Isaac Morland <isaac.morland@gmail.com>, Robert Haas <robertmhaas@gmail.com>, Jeff Davis <pgsql@j-davis.com>, PostgreSQL Hackers <pgsql-hackers@lists.postgresql.org>
Date: 2024-10-31T16:18:44Z
Lists: pgsql-hackers

Commits

Same data as JSON: GET /api/v1/messages/:b64id/commits the thread's linked commits as JSON, with link sources. API reference →

  1. Rename gist stratnum support function

  2. Remove support for temporal RESTRICT foreign keys

  3. Cache NO ACTION foreign keys separately from RESTRICT foreign keys

  4. Fix NO ACTION temporal foreign keys when the referenced endpoints change

  5. Improve whitespace in without_overlaps test

  6. Tests for logical replication with temporal keys

  7. Support for GiST in get_equal_strategy_number()

  8. Make the conditions in IsIndexUsableForReplicaIdentityFull() more explicit

  9. Replace get_equal_strategy_number_for_am() by get_equal_strategy_number()

  10. Improve internal logical replication error for missing equality strategy

  11. Simplify IsIndexUsableForReplicaIdentityFull()

  12. Fix ALTER TABLE / REPLICA IDENTITY for temporal tables

  13. doc: Update pg_constraint.conexclop docs for WITHOUT OVERLAPS

  14. doc: Add PERIOD to ALTER TABLE reference docs

  15. doc: Add WITHOUT OVERLAPS to ALTER TABLE reference docs

  16. Add temporal FOREIGN KEY contraints

  17. Add temporal PRIMARY KEY and UNIQUE constraints

  18. Add stratnum GiST support function

  19. Avoid crashing when a JIT-inlined backend function throws an error.

  20. Revert temporal primary keys and foreign keys

  21. Fix ON CONFLICT DO NOTHING/UPDATE for temporal indexes

  22. Add test for REPLICA IDENTITY with a temporal key

  23. Use half-open interval notation in without_overlaps tests

  24. Use daterange and YMD in without_overlaps tests instead of tsrange.

  25. Rename pg_constraint.conwithoutoverlaps to conperiod

  26. Fix comment on gist_stratnum_btree

  27. Add missing TAP test name

  28. Improve error handling of HMAC computations

  29. Rename functions to avoid future conflicts

Attachments

On 10/24/24 17:22, Paul Jungwirth wrote:
> On 10/21/24 14:46, Paul Jungwirth wrote:
>> Here is a new set of patches, including new patches to (1) fix logical replication with WITHOUT 
>> OVERLAPS indexes and (2) address some documentation lapses pointed out in jian he's feedback. 
>> Since all that is against the already-commited PK/UNIQUE/FK work, I've kept them separate here 
>> from the FOR PORTION OF etc patches. I've also added the logical replication problem to the v18 
>> Open Items wiki page.
> 
> New patches attached to fix some conflicts. I don't think there is anything else except cleaning up 
> some sloppy white space.

Hi Hackers,

Here are some more updates. I think everything is ready except for the final patch adding PERIODs, 
which still needs a little more work.

The biggest change here is a new patch to expose FOR PORTION OF details to plpgsql triggers via the 
new TG_PERIOD_NAME and TG_PERIOD_BOUNDS variables. These were already available to C functions (and 
we use them in the RI triggers), but now people will be able to access them via plpgsql as well.
One thing I don't love is that TG_PERIOD_BOUNDS is a string, because it needs to have a type at the 
time you create the function, and the type of the FOR PORTION OF column could be anything: 
daterange, tsrange, inetrange, textmultirange, whatever. If anyone has a better idea, I'm open to 
suggestions. This patch is not really essential, but I thought authors of plpgsql triggers might 
like to have it.

I also started working on allowing FOR PORTION OF in FDW updates/deletes (not included here). As far 
as I can see, nothing needs to change about the API, because the FOR PORTION OF details are simply 
passed as part of the node tree. We just have to remove the ereport that says FDW FOR PORTION OF is 
unsupported. Then within each FDW you have to use the new FOR PORTION OF node to do the right thing 
on the remote table. So I'm updating postgres_fdw to do that.

But beyond the *technical* need, do we need something to clue in FDW developers that these queries 
are a possibility? With no changes to postgres_fdw, a FOR PORTION OF update/delete gets executed; it 
just loses the FOR PORTION OF meaning. So we update/delete too much. That seems dangerous. It makes 
me *want* to change the API, so that developers must address the possibility. But I don't want to 
make things cluttered either. Any thoughts?

Rebased to fb7e27abfb.

Yours,

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