Re: CREATE TABLE LIKE INCLUDING INDEXES support
От | Neil Conway |
---|---|
Тема | Re: CREATE TABLE LIKE INCLUDING INDEXES support |
Дата | |
Msg-id | 1184571999.11492.23.camel@goldbach обсуждение исходный текст |
Ответ на | Re: CREATE TABLE LIKE INCLUDING INDEXES support (NikhilS <nikkhils@gmail.com>) |
Ответы |
Re: CREATE TABLE LIKE INCLUDING INDEXES support
|
Список | pgsql-patches |
On Tue, 2007-10-07 at 12:53 +0530, NikhilS wrote: > Yes, in the CREATE..LIKE case, options will be NULL and in the normal > CREATE..INDEX case inhreloptions will be NULL. Note that options is a > List of DefElem entries, whereas inhreloptions is a char pointer. Hmm, right -- ugly. I'll just stick with your approach. BTW, I notice a problem with the patch as implemented: # create table abc (a int, b int); CREATE TABLE # create index abc_a_idx on abc using hash (a); CREATE INDEX # create index abc_a_idx2 on abc (a); CREATE INDEX # create table abc2 (like abc including indexes); CREATE TABLE # \d abc2 Table "public.abc2" Column | Type | Modifiers --------+---------+----------- a | integer | b | integer | Indexes: "abc2_a_key" hash (a) This occurs because transformIndexConstraints() eliminates "duplicate" indexes from the index list by looking for two indexes with equal() column lists. This makes some sense for the normal CREATE TABLE case, but the above behavior is certainly objectionable -- when the access method differs it is merely surprising, but when partial indexes are involved it is surely a bug. One way to fix this would be to check for duplicates by comparing all the fields of the two IndexStmts, *except* the index name and "is PK?" status. But that's ugly -- it seems much cleaner to keep index definitions arising from LIKE ... INCLUDING INDEXES in a separate list from the indexes derived from constraints. Attached is a revised patch that does that. Barring any objections, I'll apply this to HEAD tomorrow. -Neil
Вложения
В списке pgsql-patches по дате отправления: