Re: CREATE TABLE LIKE INCLUDING INDEXES support
От | Neil Conway |
---|---|
Тема | Re: CREATE TABLE LIKE INCLUDING INDEXES support |
Дата | |
Msg-id | 1177714750.6440.160.camel@localhost.localdomain обсуждение исходный текст |
Ответ на | Re: CREATE TABLE LIKE INCLUDING INDEXES support (Bruce Momjian <bruce@momjian.us>) |
Ответы |
Re: CREATE TABLE LIKE INCLUDING INDEXES support
Re: CREATE TABLE LIKE INCLUDING INDEXES support |
Список | pgsql-patches |
This patch needs more work. How carefully did you test it? * the patch failed to copy index constraints if there was not also at least one CHECK constraint defined on the table * the patch is broken for expressional indexes, and silently omits copying the predicate that may be associated with an index. It also doesn't copy the index's amoptions (WITH clause), or the NULLS FIRST/etc. options that may be associated with any of the index's columns. In other words, copying column names does not suffice to duplicate the index constraint. Perhaps the right fix is to implement support for INCLUDING INDEXES, and then use that code to copy the definition of any constraint indexes in INCLUDING INDEXES? * should we copy invalid indexes? I suppose there's nothing wrong with copying them... * we should probably hold the AccessShareLock on copied indexes till end of xact, per the comments at the end of transformInhRelation() * index_open() should be matched with index_close(), not relation_close(). (In the current implementation, index_close() and relation_close() happen to be identical, so it still worked.) I've attached a revised version of the patch, but I didn't fix the second or third bullets in the list. -Neil
Вложения
В списке pgsql-patches по дате отправления: