Re: Typo in doc or wrong EXCLUDE implementation

From: KES <kes-kes(at)yandex(dot)ru>
To: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>, Bruce Momjian <bruce(at)momjian(dot)us>
Cc: PostgreSQL-development <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: Typo in doc or wrong EXCLUDE implementation
Date: 2018-08-09 10:11:05
Message-ID: 37593701533809465@sas1-87f9feb8d943.qloud-c.yandex.net
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-docs pgsql-hackers

Bruce:
>Yes, it would work, but doing that only for equality would be surprising
to many people

Why surprising? It is [documented](https://www.postgresql.org/docs/current/static/sql-createtable.html#sql-createtable-exclude):
>If all of the specified operators test for equality, this is equivalent to a UNIQUE constraint, although an ordinary unique constraint will be faster.

Thus the UNIQUE constraint is just particular case of exclusion constraint, is not?

Tom
>It's less efficient (1) and less portable
Yes, portability has matter, but more general SQL would be more efficient at developer hours to support such application in compare to writing many particular SQL's (one SQL expression is better than two which do same job). Personally I would close the eyes on portability in favor of using modern features (looking forward for inclusion constraint)

For speed efficiency (1) this particular case of exclusion constraint can be implemented via btree-based uniqueness. (like uniqueness is implemented via indexes under the hood. but the implementaion details have no matter as for me)

08.08.2018, 16:51, "Tom Lane" <tgl(at)sss(dot)pgh(dot)pa(dot)us>:
> Bruce Momjian <bruce(at)momjian(dot)us> writes:
>>  On Wed, Aug 8, 2018 at 01:55:53PM +0300, KES wrote:
>>>  If such exclusion constraint would be marked as UNIQUE we can use it for FK while implementing temporal/bi-temporal tables.
>
>>  Yes, it would work, but doing that only for equality would be surprising
>>  to many people because exclusion constraints are more general than
>>  equality comparisons.
>
> In general, we should be discouraging people from using EXCLUDE syntax
> with simple equality operators, not encouraging them to do so. It's
> less efficient and less portable than a regular btree-based uniqueness
> constraint. So I think this proposal is a bad idea regardless of
> whether it'd be technically feasible or not.
>
>                         regards, tom lane

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Michael Paquier 2018-08-09 10:28:33 Re: Improve behavior of concurrent TRUNCATE
Previous Message David Rowley 2018-08-09 09:53:46 Re: 9.6.10 build warning on Fedora 28

Browse pgsql-docs by date

  From Date Subject
Next Message Bruce Momjian 2018-08-09 14:14:33 Re: Parameter types are inferred from context of first use only.
Previous Message PG Doc comments form 2018-08-09 08:54:16 Doc update