Re: adding support for zero-attribute unique/etc keys

Brendan Jurd <direvus(at)gmail(dot)com> writes:
> On 26 March 2013 05:04, Darren Duncan <darren(at)darrenduncan(dot)net> wrote:
>> On 2013.03.25 1:17 AM, Albe Laurenz wrote:
>>> The desired effect can be had today with a unique index:
>>> CREATE TABLE singleton (id integer);
>>> CREATE UNIQUE INDEX singleton_idx ON singleton((1));

>> Okay, that is helpful, and less of a kludge than what I was doing, but it is
>> still a kludge compared to what I'm proposing, which I see as elegant.

> FWIW I think an index on (TRUE) expresses the intention more clearly
> than an index on () would.

> I don't have any objection to the purely logical sense of the
> zero-attribute key, but it's hard to see the pragmatic value.

Yeah. Other problems include the potential introduction of
non-spec-compliant entries in the information_schema, breakage of
clients that look at the catalogs and aren't expecting to find indexes
of this sort, etc etc. (Not even to mention the bugs that would be
induced in the backend itself; eg I doubt most of the index access
methods would cope with this without changes.)

Given that there's already a perfectly nice albeit non-spec-compliant
way to get the effect, I can't see the value of doing a lot of work
to create a different non-spec-compliant way.

regards, tom lane