Обсуждение: PERIOD foreign key feature
In this commit:
commit 34768ee3616
Author: Peter Eisentraut <peter@eisentraut.org>
Date: Sun Mar 24 07:37:13 2024 +0100
Add temporal FOREIGN KEY contraints
Add PERIOD clause to foreign key constraint definitions. This is
supported for range and multirange types. Temporal foreign keys check
for range containment instead of equality.
This feature matches the behavior of the SQL standard temporal foreign
keys, but it works on PostgreSQL's native ranges instead of SQL's
"periods", which don't exist in PostgreSQL (yet).
Reference actions ON {UPDATE,DELETE} {CASCADE,SET NULL,SET DEFAULT}
are not supported yet.
Author: Paul A. Jungwirth <pj@illuminatedcomputing.com>
Reviewed-by: Peter Eisentraut <peter@eisentraut.org>
Reviewed-by: jian he <jian.universality@gmail.com>
Discussion:
https://www.postgresql.org/message-id/flat/CA+renyUApHgSZF9-nd-a0+OPGharLQLO=mDHcY4_qQ0+noCUVg@mail.gmail.com
this text was added to create_table.sgml:
In addition, the referenced table must have a primary
key or unique constraint declared with <literal>WITHOUT
--> OVERLAPS</literal>. Finally, if one side of the foreign key
--> uses <literal>PERIOD</literal>, the other side must too. If the
<replaceable class="parameter">refcolumn</replaceable> list is
omitted, the <literal>WITHOUT OVERLAPS</literal> part of the
primary key is treated as if marked with <literal>PERIOD</literal>.
In the two marked lines, it says "if one side of the foreign key uses
PERIOD, the other side must too." However, looking at the example
queries, it seems like if the foreign side has PERIOD, the primary side
must have WITHOUT OVERLAPS, not PERIOD.
Does this doc text need correcting?
--
Bruce Momjian <bruce@momjian.us> https://momjian.us
EDB https://enterprisedb.com
Only you can decide what is important to you.
On Tue, May 7, 2024 at 7:54 AM Bruce Momjian <bruce@momjian.us> wrote:
In this commit:
commit 34768ee3616
Author: Peter Eisentraut <peter@eisentraut.org>
Date: Sun Mar 24 07:37:13 2024 +0100
Add temporal FOREIGN KEY contraints
Add PERIOD clause to foreign key constraint definitions. This is
supported for range and multirange types. Temporal foreign keys check
for range containment instead of equality.
This feature matches the behavior of the SQL standard temporal foreign
keys, but it works on PostgreSQL's native ranges instead of SQL's
"periods", which don't exist in PostgreSQL (yet).
Reference actions ON {UPDATE,DELETE} {CASCADE,SET NULL,SET DEFAULT}
are not supported yet.
Author: Paul A. Jungwirth <pj@illuminatedcomputing.com>
Reviewed-by: Peter Eisentraut <peter@eisentraut.org>
Reviewed-by: jian he <jian.universality@gmail.com>
Discussion: https://www.postgresql.org/message-id/flat/CA+renyUApHgSZF9-nd-a0+OPGharLQLO=mDHcY4_qQ0+noCUVg@mail.gmail.com
this text was added to create_table.sgml:
In addition, the referenced table must have a primary
key or unique constraint declared with <literal>WITHOUT
--> OVERLAPS</literal>. Finally, if one side of the foreign key
--> uses <literal>PERIOD</literal>, the other side must too. If the
<replaceable class="parameter">refcolumn</replaceable> list is
omitted, the <literal>WITHOUT OVERLAPS</literal> part of the
primary key is treated as if marked with <literal>PERIOD</literal>.
In the two marked lines, it says "if one side of the foreign key uses
PERIOD, the other side must too." However, looking at the example
queries, it seems like if the foreign side has PERIOD, the primary side
must have WITHOUT OVERLAPS, not PERIOD.
Does this doc text need correcting?
The text is factually correct, though a bit hard to parse.
"the other side" refers to the part after "REFERENCES":
FOREIGN KEY ( column_name [, ... ] [, PERIOD column_name ] ) REFERENCES reftable [ ( refcolumn [, ... ] [, PERIOD column_name ] ) ]
***(shouldn't the second occurrence be [, PERIOD refcolum] ?)
The text is pointing out that since the refcolumn specification is optional you may very well not see a second PERIOD keyword in the clause. Instead it will be inferred from the PK.
Maybe:
Finally, if the foreign key has a PERIOD column_name specification the corresponding refcolumn, if present, must also be marked PERIOD. If the refcolumn clause is omitted, and thus the reftable's primary key constraint chosen, the primary key must have its final column marked WITHOUT OVERLAPS.
David J.
On 5/7/24 08:23, David G. Johnston wrote:
> On Tue, May 7, 2024 at 7:54 AM Bruce Momjian <bruce@momjian.us <mailto:bruce@momjian.us>> wrote:
> In the two marked lines, it says "if one side of the foreign key uses
> PERIOD, the other side must too." However, looking at the example
> queries, it seems like if the foreign side has PERIOD, the primary side
> must have WITHOUT OVERLAPS, not PERIOD.
>
> Does this doc text need correcting?
>
>
> The text is factually correct, though a bit hard to parse.
>
> "the other side" refers to the part after "REFERENCES":
>
> FOREIGN KEY ( column_name [, ... ] [, PERIOD column_name ] ) REFERENCES reftable [ ( refcolumn [,
> ... ] [, PERIOD column_name ] ) ]
>
> ***(shouldn't the second occurrence be [, PERIOD refcolum] ?)
>
> The text is pointing out that since the refcolumn specification is optional you may very well not
> see a second PERIOD keyword in the clause. Instead it will be inferred from the PK.
>
> Maybe:
>
> Finally, if the foreign key has a PERIOD column_name specification the corresponding refcolumn, if
> present, must also be marked PERIOD. If the refcolumn clause is omitted, and thus the reftable's
> primary key constraint chosen, the primary key must have its final column marked WITHOUT OVERLAPS.
Yes, David is correct here on all points. I like his suggestion to clarify the language here also.
If you need a patch from me let me know, but I assume it's something a committer can just make happen?
Yours,
--
Paul ~{:-)
pj@illuminatedcomputing.com
On 07.05.24 18:43, Paul Jungwirth wrote: > On 5/7/24 08:23, David G. Johnston wrote: >> On Tue, May 7, 2024 at 7:54 AM Bruce Momjian <bruce@momjian.us >> <mailto:bruce@momjian.us>> wrote: >> In the two marked lines, it says "if one side of the foreign key uses >> PERIOD, the other side must too." However, looking at the example >> queries, it seems like if the foreign side has PERIOD, the primary >> side >> must have WITHOUT OVERLAPS, not PERIOD. >> >> Does this doc text need correcting? >> >> >> The text is factually correct, though a bit hard to parse. >> >> "the other side" refers to the part after "REFERENCES": >> >> FOREIGN KEY ( column_name [, ... ] [, PERIOD column_name ] ) >> REFERENCES reftable [ ( refcolumn [, ... ] [, PERIOD column_name ] ) ] >> >> ***(shouldn't the second occurrence be [, PERIOD refcolum] ?) >> >> The text is pointing out that since the refcolumn specification is >> optional you may very well not see a second PERIOD keyword in the >> clause. Instead it will be inferred from the PK. >> >> Maybe: >> >> Finally, if the foreign key has a PERIOD column_name specification the >> corresponding refcolumn, if present, must also be marked PERIOD. If >> the refcolumn clause is omitted, and thus the reftable's primary key >> constraint chosen, the primary key must have its final column marked >> WITHOUT OVERLAPS. > > Yes, David is correct here on all points. I like his suggestion to > clarify the language here also. If you need a patch from me let me know, > but I assume it's something a committer can just make happen? In principle yes, but it's also very helpful if someone produces an actual patch file, with complete commit message, credits, mailing list link, etc.
On Wed, May 8, 2024 at 02:29:34PM +0200, Peter Eisentraut wrote: > > > Finally, if the foreign key has a PERIOD column_name specification > > > the corresponding refcolumn, if present, must also be marked > > > PERIOD. If the refcolumn clause is omitted, and thus the reftable's > > > primary key constraint chosen, the primary key must have its final > > > column marked WITHOUT OVERLAPS. > > > > Yes, David is correct here on all points. I like his suggestion to > > clarify the language here also. If you need a patch from me let me know, > > but I assume it's something a committer can just make happen? > > In principle yes, but it's also very helpful if someone produces an actual > patch file, with complete commit message, credits, mailing list link, etc. I am ready to do the work, but waited a day for Peter to reply, since he was the author of the text. -- Bruce Momjian <bruce@momjian.us> https://momjian.us EDB https://enterprisedb.com Only you can decide what is important to you.
On 5/8/24 07:44, Bruce Momjian wrote:
> On Wed, May 8, 2024 at 02:29:34PM +0200, Peter Eisentraut wrote:
>>> Yes, David is correct here on all points. I like his suggestion to
>>> clarify the language here also. If you need a patch from me let me know,
>>> but I assume it's something a committer can just make happen?
>>
>> In principle yes, but it's also very helpful if someone produces an actual
>> patch file, with complete commit message, credits, mailing list link, etc.
>
> I am ready to do the work, but waited a day for Peter to reply, since he
> was the author of the text.
Here is a patch for this.
Yours,
--
Paul ~{:-)
pj@illuminatedcomputing.com
Вложения
On Wed, May 8, 2024 at 08:47:45PM -0700, Paul Jungwirth wrote: > On 5/8/24 07:44, Bruce Momjian wrote: > > On Wed, May 8, 2024 at 02:29:34PM +0200, Peter Eisentraut wrote: > > > > Yes, David is correct here on all points. I like his suggestion to > > > > clarify the language here also. If you need a patch from me let me know, > > > > but I assume it's something a committer can just make happen? > > > > > > In principle yes, but it's also very helpful if someone produces an actual > > > patch file, with complete commit message, credits, mailing list link, etc. > > > > I am ready to do the work, but waited a day for Peter to reply, since he > > was the author of the text. > > Here is a patch for this. Thanks, patch applied. -- Bruce Momjian <bruce@momjian.us> https://momjian.us EDB https://enterprisedb.com Only you can decide what is important to you.