Re: SQL:2011 application time
Paul A Jungwirth <pj@illuminatedcomputing.com>
Commits
GET /api/v1/messages/:b64id/commits
the thread's linked commits as JSON, with link sources.
API reference →
-
Rename gist stratnum support function
- 32edf732e8dc 18.0 landed
-
Remove support for temporal RESTRICT foreign keys
- b83e8a2ca2eb 18.0 landed
-
Cache NO ACTION foreign keys separately from RESTRICT foreign keys
- 9926f854d077 18.0 landed
-
Fix NO ACTION temporal foreign keys when the referenced endpoints change
- 1772d554b089 18.0 landed
-
Improve whitespace in without_overlaps test
- 888d4523f0c2 18.0 landed
-
Tests for logical replication with temporal keys
- 939b0908c87a 18.0 landed
-
Support for GiST in get_equal_strategy_number()
- 74edabce7a33 18.0 landed
-
Make the conditions in IsIndexUsableForReplicaIdentityFull() more explicit
- 13544e790ef8 18.0 landed
-
Replace get_equal_strategy_number_for_am() by get_equal_strategy_number()
- a2a475b011cf 18.0 landed
-
Improve internal logical replication error for missing equality strategy
- 321c287351f7 18.0 landed
-
Simplify IsIndexUsableForReplicaIdentityFull()
- 7727049e8f66 18.0 landed
-
Fix ALTER TABLE / REPLICA IDENTITY for temporal tables
- 79b575d3bc09 18.0 landed
-
doc: Update pg_constraint.conexclop docs for WITHOUT OVERLAPS
- f683ba0867da 18.0 landed
-
doc: Add PERIOD to ALTER TABLE reference docs
- d56af4c882e2 18.0 landed
-
doc: Add WITHOUT OVERLAPS to ALTER TABLE reference docs
- bf621059500b 18.0 landed
-
Add temporal FOREIGN KEY contraints
- 89f908a6d0ac 18.0 landed
- 34768ee36165 17.0 landed
-
Add temporal PRIMARY KEY and UNIQUE constraints
- fc0438b4e805 18.0 landed
- 46a0cd4cefb4 17.0 landed
-
Add stratnum GiST support function
- 7406ab623fee 18.0 landed
- 6db4598fcb82 17.0 landed
-
Avoid crashing when a JIT-inlined backend function throws an error.
- 5d6c64d29097 17.0 cited
-
Revert temporal primary keys and foreign keys
- 8aee330af55d 17.0 landed
-
Fix ON CONFLICT DO NOTHING/UPDATE for temporal indexes
- 144c2ce0cc75 17.0 landed
-
Add test for REPLICA IDENTITY with a temporal key
- 482e108cd38d 17.0 landed
-
Use half-open interval notation in without_overlaps tests
- 5577a71fb0cc 17.0 landed
-
Use daterange and YMD in without_overlaps tests instead of tsrange.
- a88c800deb6f 17.0 landed
-
Rename pg_constraint.conwithoutoverlaps to conperiod
- 030e10ff1a36 17.0 landed
-
Fix comment on gist_stratnum_btree
- 86232a49a437 17.0 landed
-
Add missing TAP test name
- 1ab763fc22ad 16.0 cited
-
Improve error handling of HMAC computations
- 5513dc6a304d 15.0 cited
-
Rename functions to avoid future conflicts
- ee419607381d 15.0 landed
Attachments
- v24-0001-Fix-comment-on-gist_stratnum_btree.patch (text/x-patch) patch v24-0001
- v24-0002-Add-GiST-referencedagg-support-func.patch (text/x-patch) patch v24-0002
- v24-0003-Add-temporal-FOREIGN-KEYs.patch (text/x-patch) patch v24-0003
- v24-0004-Add-multi-range_without_portion-proc-operator.patch (text/x-patch) patch v24-0004
- v24-0005-Add-UPDATE-DELETE-FOR-PORTION-OF.patch (text/x-patch) patch v24-0005
- v24-0006-Add-CASCADE-SET-NULL-SET-DEFAULT-for-temporal-fo.patch (text/x-patch) patch v24-0006
- v24-0007-Add-PERIODs.patch (text/x-patch) patch v24-0007
On 1/24/24 08:32, Peter Eisentraut wrote:
> On 18.01.24 04:59, Paul Jungwirth wrote:
>> Here are new patches consolidating feedback from several emails.
>
> I have committed 0001 and 0002 (the primary key support).
Thanks Peter! I noticed the comment on gist_stratnum_btree was out-of-date, so here is a tiny patch
correcting it.
Also the remaining patches with some updates:
I fixed the dependency issues with PERIODs and their (hidden) GENERATED range columns. This has been
causing test failures and bugging me since I reordered the patches at PgCon, so I'm glad to finally
clean it up. The PERIOD should have an INTERNAL dependency on the range column, but then when you
dropped the table the dependency code thought the whole table was part of the INTERNAL dependency,
so the drop would fail. The PERIOD patch here fixes the dependency logic. (I guess this is the first
time a column has been an internal dependency of something.)
I also fixed an error message when you try to change the type of a start/end column used by a
PERIOD. Previously the error message would complain about the GENERATED column, not the PERIOD,
which seems confusing. In fact it was non-deterministic, depending on which pg_depend record the
index returned first.
On 12/6/23 05:22, jian he wrote:
> tring to the following TODO:
> // TODO: Need to save context->mtstate->mt_transition_capture? (See
> comment on ExecInsert)
>
> but failed.
> I also attached the trial, and also added the related test.
>
> You can also use the test to check portion update with insert trigger
> with "referencing old table as old_table new table as new_table"
> situation.
Thank you for the very helpful test case here. I fixed the issue of not passing along the transition
table. But there is still more work to do here I think:
- The AFTER INSERT FOR EACH ROW triggers have *both* leftover rows in the NEW table. Now the docs do
say that for AFTER triggers, a named transition table can see all the changes from the *statement*
(although that seems pretty weird to me), but the inserts are two *separate* statements. I think the
SQL:2011 standard is fairly clear about that. So each time the trigger fires we should still get
just one row in the transition table.
- The AFTER INSERT FOR EACH STATEMENT triggers never fire. That happens outside ExecInsert (in
ExecModifyTable). In fact there is a bunch of stuff in ExecModifyTable that maybe we need to do when
we insert leftovers. Do we even need a separate exec node, perhaps wrapping ExecModifyTable? I'm not
sure that would give us the correct trigger ordering for the triggers on the implicit insert
statement(s) vs the explicit update/delete statement, so maybe it does all need to be part of the
single node. But still I think we need to be more careful about memory, especially the per-tuple
context.
I'll keep working on that, but at least in this round of patches the transition tables aren't
missing completely.
My plan is still to replace the 'p' amoppurpose operators with just support functions. I want to do
that next, although as Peter requested I'll also start focusing more narrowly on the foreign key
patches.
Rebased to 46a0cd4cef.
Yours,
--
Paul ~{:-)
pj@illuminatedcomputing.com