Re: CREATE TABLE LIKE INCLUDING INDEXES support
От | Tom Lane |
---|---|
Тема | Re: CREATE TABLE LIKE INCLUDING INDEXES support |
Дата | |
Msg-id | 12473.1179432272@sss.pgh.pa.us обсуждение исходный текст |
Ответ на | Re: CREATE TABLE LIKE INCLUDING INDEXES support (Gregory Stark <stark@enterprisedb.com>) |
Ответы |
Re: CREATE TABLE LIKE INCLUDING INDEXES support
|
Список | pgsql-patches |
Gregory Stark <stark@enterprisedb.com> writes: > "Tom Lane" <tgl@sss.pgh.pa.us> writes: >> It'd be contrary to SQL spec. The UNIQUE constraint takes a list of >> column names, full stop. > Does the SQL spec actually specify what happens if you provide an > non-compliant table definition like this? It does not. We could accept expressions there, and pray that the SQL committee never extends the spec syntax in a direction incompatible with that. That seems like a pretty risky thing to do though. [ thinks... ] I think actually the prior discussions about this have suggested importing our CREATE INDEX argument-list syntax into the UNIQUE/PRIMARY KEY syntax, lock stock and barrel. Between the optional opclass and sort direction and the slightly klugy requirement to parenthesize expressions, that seemed clearly at huge risk of putting us behind the compatibility eight-ball. You could make an argument that the only plausible way that the committee would extend the syntax would be to allow plain expressions instead of column names, and thus that allowing that but not our other extensions would be safe. You might be right about that ... or not. The fact that the committee still hasn't made this seemingly-obvious extension makes me wonder if they have plans we don't know about. There are certainly a ton of bells and whistles in SQL2003 that're far less useful than this would be. In any case there will always be features in CREATE INDEX that we daren't drop into the standard constraint syntax, so the argument for importing just this one seems a bit weak. BTW, has anyone checked to see if Oracle and/or DB2 allow expressions here? I think it's unlikely the committee would do anything to break the standards compliance of those guys, so we might be safe in following their lead if there is one. regards, tom lane
В списке pgsql-patches по дате отправления: