From: | Paul A Jungwirth <pj(at)illuminatedcomputing(dot)com> |
---|---|
To: | David Steele <david(at)pgmasters(dot)net> |
Cc: | Jeff Davis <pgsql(at)j-davis(dot)com>, Heikki Linnakangas <hlinnaka(at)iki(dot)fi>, PostgreSQL-development <pgsql-hackers(at)postgresql(dot)org> |
Subject: | Re: SQL:2011 PERIODS vs Postgres Ranges? |
Date: | 2019-06-17 04:54:40 |
Message-ID: | CA+renyV9_XBWLjKSVFHxO6Y98SBuvB=a9nb3Y6UjzaUDptTJrQ@mail.gmail.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
> Here is that patch. I've changed the title from "temporal_pks" to
> "temporal_fks" but it includes both.
Here are rebased patches to add temporal PKs and FKs. Note they depend
on my other commitfest entry adding a range_agg function. The PKs
patch should be applied first, then the FKs patch. These are mostly
the same as before, but I've added a small optimization to the FK
patch. The traditional FK code skips the UPDATE triggers if the PK/FK
columns didn't change. For temporal RI, we can broaden the condition:
on a PK update, if the new PK range is a superset of the old (and the
other parts of the key are equal), we can skip the check. On an FK
update, if the new FK range is a subset of the old (and the other
parts of the key are equal), we can skip the check.
These are still very WIP patches. They include a bunch of TODO
comments where I'm hoping to get feedback. Also their "taste" is
surely questionable. In many cases I took the least-obtrusive path
even where that might not be the best one. If anyone wants to offer
some corrections, I would gratefully pay attention. :-)
My plan is to work on UPDATE/DELETE FOR PORTION OF next, then use that
to add CASCADE functionality to temporal FKs. I've started reading how
executor nodes work, but I'll probably reach out with some questions.
. . . :-) Also I need to decide how triggers should behave in a
temporal update/delete. I have my own opinion about what is sensible,
but I haven't found guidance in the standard, so I'm going to see what
other RDBMSes are doing. (If someone has a reference to a part of the
standard I overlooked, let me know! :-)
Yours,
Paul
Attachment | Content-Type | Size |
---|---|---|
temporal_fks_v0002.patch | application/octet-stream | 99.2 KB |
temporal_pks_v0004.patch | application/octet-stream | 28.9 KB |
From | Date | Subject | |
---|---|---|---|
Next Message | Michael Paquier | 2019-06-17 05:51:45 | Race conditions with TAP test for syncrep |
Previous Message | Pavel Stehule | 2019-06-17 03:31:40 | Re: proposal: new polymorphic types - commontype and commontypearray |