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
uniqueconstraint 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
applicationin compare to writing many particular SQL's (one SQL expression is better than two which do same job).
PersonallyI 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.
(likeuniqueness 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@sss.pgh.pa.us>:
> Bruce Momjian <bruce@momjian.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-temporaltables.
>
>> 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