Received: from malur.postgresql.org ([217.196.149.56]) by arkaria.postgresql.org with esmtps (TLS1.3) tls TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 (Exim 4.94.2) (envelope-from ) id 1s4NvD-003MbW-Sl for pgsql-hackers@arkaria.postgresql.org; Tue, 07 May 2024 16:44:07 +0000 Received: from localhost ([127.0.0.1] helo=malur.postgresql.org) by malur.postgresql.org with esmtp (Exim 4.94.2) (envelope-from ) id 1s4NvA-003vM6-JK for pgsql-hackers@arkaria.postgresql.org; Tue, 07 May 2024 16:44:05 +0000 Received: from makus.postgresql.org ([2001:4800:3e1:1::229]) by malur.postgresql.org with esmtps (TLS1.3) tls TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 (Exim 4.94.2) (envelope-from ) id 1s4NvA-003vLq-3e for pgsql-hackers@lists.postgresql.org; Tue, 07 May 2024 16:44:05 +0000 Received: from mail-pf1-x436.google.com ([2607:f8b0:4864:20::436]) by makus.postgresql.org with esmtps (TLS1.3) tls TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256 (Exim 4.94.2) (envelope-from ) id 1s4Nv7-001tpv-UH for pgsql-hackers@lists.postgresql.org; Tue, 07 May 2024 16:44:03 +0000 Received: by mail-pf1-x436.google.com with SMTP id d2e1a72fcca58-6f44dd41a5cso3248390b3a.0 for ; Tue, 07 May 2024 09:44:01 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=illuminatedcomputing-com.20230601.gappssmtp.com; s=20230601; t=1715100240; x=1715705040; darn=lists.postgresql.org; h=content-transfer-encoding:in-reply-to:from:content-language :references:to:subject:user-agent:mime-version:date:message-id:from :to:cc:subject:date:message-id:reply-to; bh=3Ow3l1aETiP65deUjMQgVlwo6SBtYXATabsCU7ULzDQ=; b=DR8O6627KKqmxN8vPL3I4PweM31lRa5qY8p/Bg/kaO6z7X5DkWJAbjZzDfzlaSB29z xHmEc8OTiTn1Du+H+BuGqHjm4PyxpPA+NLEQTw+4zKBJUMFm4zXgj9vnCv7EnZCj6YqV 13HX6zNQ/ipM5/zcE+vJI3AzpdCnzIqQI8i5BVeSYwugmqBkqkLBigj8leG+B7+Xx1EZ S2cjNt38uoKZi7+J32uRYWBnRgqSBg+JQueVJOeeUP969vYXxVm9wna5aVjWSK4rd87n I4BYXY64mnfq36Y4wqtDG9RLBVmswkDW547CH0zG621P00GuqMWIu599ORuMnJVvQn8W cX0g== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1715100240; x=1715705040; h=content-transfer-encoding:in-reply-to:from:content-language :references:to:subject:user-agent:mime-version:date:message-id :x-gm-message-state:from:to:cc:subject:date:message-id:reply-to; bh=3Ow3l1aETiP65deUjMQgVlwo6SBtYXATabsCU7ULzDQ=; b=gJ+RMhHoxn9V3uIFZ+qi3MDsOsZgbdMRiDsM8mJGnHSeAyF3znL1clI1J3rMnEFKd6 LHOeU5SRrR2s5Pnt1ON3DQHgCb1K1BLBeYiHg5n8lAsLYMQvj6x2q8ZGlyT3knsmiyRK e/me7w3q7wnAWh85G0vUQjR8teMHSL19r/2s7uXSZAnc4Bs0hQjIPkgre19/+yPVptoF /dTrqlh2ONDse0N/BC573WbaThssAsP3WjC9hPGZxeAibM2M7qxqOniFkbtmVXCEM5t+ Lb1dbwwkWKvfMADB0Y65rwJYgJxk/w9CYITfb4P03jGpCfKFfyDxNDhRYtbeFl3ih2uP 8gzg== X-Gm-Message-State: AOJu0YyGM4r8zq2SQXXfyTwx1FAj06SPZA6upoH2fBe1D6/zRAwFRFSo yIXFhUH3vyQ5o9jMQ6uRKOrH+rr8YsrrmtVeTUz/cgUy+qYR4U8fe8/RBm6B75G/iqkrJ+EdGSj 0 X-Google-Smtp-Source: AGHT+IEp2Y3D3riym1KJ1p3EjbZsLASIaqT4sgxrnj5/zHL9D5UaJ6Ge4R1Nq3U43+W5xjzHbfOL4g== X-Received: by 2002:a05:6a20:7355:b0:1af:9369:9a3 with SMTP id adf61e73a8af0-1afc8d96dcdmr282549637.44.1715100239793; Tue, 07 May 2024 09:43:59 -0700 (PDT) Received: from [192.168.2.139] ([50.39.255.79]) by smtp.googlemail.com with ESMTPSA id s26-20020aa78d5a000000b006f4476e0785sm8453652pfe.34.2024.05.07.09.43.59 for (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Tue, 07 May 2024 09:43:59 -0700 (PDT) Message-ID: <4a630353-11bb-4e3a-ae61-5ec10abe7aed@illuminatedcomputing.com> Date: Tue, 7 May 2024 09:43:58 -0700 MIME-Version: 1.0 User-Agent: Mozilla Thunderbird Subject: Re: PERIOD foreign key feature To: pgsql-hackers@lists.postgresql.org References: Content-Language: en-US From: Paul Jungwirth In-Reply-To: Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit List-Id: List-Help: List-Subscribe: List-Post: List-Owner: List-Archive: Archived-At: Precedence: bulk On 5/7/24 08:23, David G. Johnston wrote: > On Tue, May 7, 2024 at 7:54 AM Bruce Momjian > 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