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.