Re: CREATE TABLE LIKE INCLUDING INDEXES support - Mailing list pgsql-patches

From Neil Conway
Subject Re: CREATE TABLE LIKE INCLUDING INDEXES support
Date
Msg-id 1177714750.6440.160.camel@localhost.localdomain
Whole thread Raw
In response to Re: CREATE TABLE LIKE INCLUDING INDEXES support  (Bruce Momjian <bruce@momjian.us>)
Responses Re: CREATE TABLE LIKE INCLUDING INDEXES support
Re: CREATE TABLE LIKE INCLUDING INDEXES support
List 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


Attachment

pgsql-patches by date:

Previous
From: Bruce Momjian
Date:
Subject: Re: New version of GENERATED/IDENTITY, was Re: parser dilemma
Next
From: Neil Conway
Date:
Subject: Re: Hash function for numeric (WIP)