From: | Paul Jungwirth <pj(at)illuminatedcomputing(dot)com> |
---|---|
To: | Peter Eisentraut <peter(dot)eisentraut(at)enterprisedb(dot)com> |
Cc: | Corey Huinker <corey(dot)huinker(at)gmail(dot)com>, PostgreSQL Hackers <pgsql-hackers(at)lists(dot)postgresql(dot)org>, Jaime Casanova <jcasanov(at)systemguards(dot)com(dot)ec>, jian he <jian(dot)universality(at)gmail(dot)com>, Daniel Gustafsson <daniel(at)yesql(dot)se> |
Subject: | Re: SQL:2011 application time |
Date: | 2023-08-31 21:26:31 |
Message-ID: | ab4cf49c-9839-3426-5114-f596fa9ee76b@illuminatedcomputing.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
On 7/12/23 01:24, Peter Eisentraut wrote:
> On 07.07.23 03:03, Paul A Jungwirth wrote:
>> Here are some new patch files based on discussions from PGCon.
>
> Here are a few fixup patches to get things building without warnings and
> errors.
>
> The last patch (your 0005) fails the regression test for me and it
> didn't appear to be a trivial problem, so please take another look at
> that sometime. (Since it's the last patch, it's obviously lower priority.)
Hello,
Here are the latest patches for my temporal tables work. They are
rebased on e8d74ad6 from Aug 31.
I incorporated Peter's edits mentioned above and have made various other
improvements.
The most significant change is support for partitioned tables. Those now
work with temporal PRIMARY KEY and UNIQUE constraints, FOR PORTION OF
commands, and FOREIGN KEYs.
I've tried to clean up the first four patches to get them ready for
committing, since they could get committed before the PERIOD patch. I
think there is a little more cleanup needed but they should be ready for
a review.
The PERIOD patch is not finished and includes some deliberately-failing
tests. I did make some progress here finishing ALTER TABLE ADD PERIOD.
I could use help handling the INTERNAL depenency from the PERIOD to its
(hidden) GENERATED column. The problem is in findDependentObjects: if
you drop the PERIOD, then Postgres automatically tries to drop the
column (correctly), but then it seems to think it needs to drop the
whole table. I think this is because a column's object address is the
table's object address plus a subaddress equaling the attno, and
findDependentObjects thinks it should drop the whole thing. I'm sure I
can sort this out, but if anyone has a suggestion it might save me some
time.
Thanks for taking a look!
Yours,
--
Paul ~{:-)
pj(at)illuminatedcomputing(dot)com
Attachment | Content-Type | Size |
---|---|---|
v13-0001-Add-temporal-PRIMARY-KEY-and-UNIQUE-constraints.patch | text/x-patch | 76.4 KB |
v13-0002-Add-temporal-FOREIGN-KEYs.patch | text/x-patch | 115.1 KB |
v13-0003-Add-UPDATE-DELETE-FOR-PORTION-OF.patch | text/x-patch | 117.3 KB |
v13-0004-Add-CASCADE-SET-NULL-SET-DEFAULT-for-temporal-fo.patch | text/x-patch | 74.6 KB |
v13-0005-Add-PERIODs.patch | text/x-patch | 130.0 KB |
From | Date | Subject | |
---|---|---|---|
Next Message | Daniel Gustafsson | 2023-08-31 21:34:53 | Re: Reducing connection overhead in pg_upgrade compat check phase |
Previous Message | Corey Huinker | 2023-08-31 21:18:32 | Re: Statistics Import and Export |