MIME-Version: 1.0
References: <CA+renyUApHgSZF9-nd-a0+OPGharLQLO=mDHcY4_qQ0+noCUVg@mail.gmail.com>
 <CACJufxFFeUHoBomd2856amDBccNVQZzA=Jrk1_FDdvSZ1+X7og@mail.gmail.com>
 <CACJufxEACgLY7YUvzo8j=iOB-z6-1QHAvMr8cUHRP7b_F_vo3A@mail.gmail.com>
 <CA+renyXHFFyq1n2+4cwcFoLXqzUhb6u6WCL6wjk8ZjP9WxTExw@mail.gmail.com>
 <f22f65c8-865d-4753-94cc-3b954c29ad5c@eisentraut.org> <feee527a-6c47-42b9-a947-2422adb45a1c@illuminatedcomputing.com>
 <CACJufxF8HyERm7SKBJ+duxAP9sTgVhaW6b-oWADANGgn-o4wPA@mail.gmail.com>
 <b4bc1ef8-4215-4cf6-933c-5ef2a2827efe@illuminatedcomputing.com>
 <85dd3ad0-fa79-46e8-a08b-c426c76825f3@eisentraut.org> <a5d8df78-9ff6-4273-8d06-6c85b5520520@illuminatedcomputing.com>
 <49c07eac-18ec-4aff-929c-e81b87df1092@eisentraut.org> <CACJufxHsYDfHK62FTHdLsgDenvJd_bEuxCiyH62Lacj7NvzX4w@mail.gmail.com>
 <d579a67c-e8d7-4eb7-ae14-f6fca01489cf@illuminatedcomputing.com>
 <1edb3b79-a4bc-43b1-80aa-2e090472fe32@eisentraut.org> <47550967-260b-4180-9791-b224859fe63e@illuminatedcomputing.com>
 <64c2b2ab-7ce9-475e-ac59-3bfec528bada@eisentraut.org> <58b6687fe9de002e4c862a412719e4f918bad987.camel@j-davis.com>
In-Reply-To: <58b6687fe9de002e4c862a412719e4f918bad987.camel@j-davis.com>
From: Robert Haas <robertmhaas@gmail.com>
Date: Tue, 21 May 2024 13:57:27 -0400
Message-ID: <CA+Tgmob518sSV4Y8F4LN3X-7+7DmExznG1wCbYrOurfPL_xBOg@mail.gmail.com>
Subject: Re: SQL:2011 application time
To: Jeff Davis <pgsql@j-davis.com>
Cc: Peter Eisentraut <peter@eisentraut.org>, Paul Jungwirth <pj@illuminatedcomputing.com>, 
	jian he <jian.universality@gmail.com>, 
	PostgreSQL Hackers <pgsql-hackers@lists.postgresql.org>
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
Archived-At: <https://www.postgresql.org/message-id/CA%2BTgmob518sSV4Y8F4LN3X-7%2B7DmExznG1wCbYrOurfPL_xBOg%40mail.gmail.com>
Precedence: bulk

On Thu, May 16, 2024 at 7:22=E2=80=AFPM Jeff Davis <pgsql@j-davis.com> wrot=
e:
> An empty range does not "bypass" the an exclusion constraint. The
> exclusion constraint has a documented meaning and it's enforced.
>
> Of course there are situations where an empty range doesn't make a lot
> of sense. For many domains zero doesn't make any sense, either.
> Consider receiving an email saying "thank you for purchasing 0
> widgets!". Check constraints seem like a reasonable way to prevent
> those kinds of problems.

I think that's true. Having infinitely many events zero-length events
scheduled at the same point in time isn't necessarily a problem: I can
attend an infinite number of simultaneous meetings if I only need to
attend them for exactly zero time.

What I think is less clear is what that means for temporal primary
keys. As Paul pointed out upthread, in every other case, a temporal
primary key is at least as unique as a regular primary key, but in
this case, it isn't. And someone might reasonably think that a
temporal primary key should exclude empty ranges just as all primary
keys exclude nulls. Or they might think the opposite.

At least, so it seems to me.

--=20
Robert Haas
EDB: http://www.enterprisedb.com