From: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
---|---|
To: | Michael Glaesemann <grzm(at)myrealbox(dot)com> |
Cc: | pgsql-general <pgsql-general(at)postgresql(dot)org>, Michael Fuhr <mike(at)fuhr(dot)org> |
Subject: | Re: Accessing composite type columns in indexes |
Date: | 2006-03-04 05:17:39 |
Message-ID: | 11251.1141449459@sss.pgh.pa.us |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-general |
Michael Glaesemann <grzm(at)myrealbox(dot)com> writes:
> Except, why doesn't it work in the CREATE TABLE statement?
The UNIQUE/PRIMARY KEY syntax only allows bare column names, per the SQL
standard. While there's not any technical reason why we couldn't extend
that syntax, there's a pretty large fear factor involved: we could find
ourselves behind the spec-compliance eight-ball if the SQL committee
exercises their prerogative to extend the syntax in some other
direction. CREATE INDEX is entirely outside the spec (as the whole
concept of indexes is outside the spec) and so we can pretty much do
what we please within that statement.
This is exactly the same reason why we don't support opclass names in
UNIQUE/PRIMARY KEY, as has been suggested several times recently, eg
http://archives.postgresql.org/pgsql-hackers/2006-03/msg00163.php
regards, tom lane
From | Date | Subject | |
---|---|---|---|
Next Message | Michael Glaesemann | 2006-03-04 05:45:18 | Re: Accessing composite type columns in indexes |
Previous Message | Michael Glaesemann | 2006-03-04 05:06:21 | Re: Accessing composite type columns in indexes |