From: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
---|---|
To: | Andres Freund <andres(at)2ndquadrant(dot)com> |
Cc: | Greg Stark <stark(at)mit(dot)edu>, PostgreSQL-development <pgsql-hackers(at)postgresql(dot)org> |
Subject: | Re: Why do we allow indexes to contain the same column more than once? |
Date: | 2014-05-01 14:08:51 |
Message-ID: | 27528.1398953331@sss.pgh.pa.us |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
Andres Freund <andres(at)2ndquadrant(dot)com> writes:
> On 2014-05-01 13:55:46 +0100, Greg Stark wrote:
>> Is there some use case for that I'm not seeing?
> Can be useful if different opclasses are used for the individual
> columns. Other than that I am not seing much use.
Yeah. This is more plausible for the advanced index types like GIST,
where different opclasses might possibly do significantly different
things. We do prohibit it for unique/pkey constraints:
regression=# create table tt(f1 int, unique(f1,f1));
ERROR: column "f1" appears twice in unique constraint
LINE 1: create table tt(f1 int, unique(f1,f1));
^
which I think is per SQL spec, and anyway there would be no way that
the constraint code would select different opclasses for the same column,
so it's clearly redundant.
regards, tom lane
From | Date | Subject | |
---|---|---|---|
Next Message | Tom Lane | 2014-05-01 14:10:46 | Re: quiet inline configure check misses a step for clang |
Previous Message | Greg Stark | 2014-05-01 14:06:39 | Re: Successor of MD5 authentication, let's use SCRAM |