Re: SQL:2011 application time

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

In response to

Responses

Browse pgsql-hackers by date

  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