Re: adding support for zero-attribute unique/etc keys - Mailing list pgsql-hackers

From Tom Lane
Subject Re: adding support for zero-attribute unique/etc keys
Date
Msg-id 22205.1364251902@sss.pgh.pa.us
Whole thread Raw
In response to Re: adding support for zero-attribute unique/etc keys  (Brendan Jurd <direvus@gmail.com>)
List pgsql-hackers
Brendan Jurd <direvus@gmail.com> writes:
> On 26 March 2013 05:04, Darren Duncan <darren@darrenduncan.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



pgsql-hackers by date:

Previous
From: Kevin Grittner
Date:
Subject: Re: Limiting setting of hint bits by read-only queries; vacuum_delay
Next
From: Greg Stark
Date:
Subject: Re: Limiting setting of hint bits by read-only queries; vacuum_delay