Skip site navigation (1) Skip section navigation (2)

Re: CREATE TABLE LIKE INCLUDING INDEXES support

From: NikhilS <nikkhils(at)gmail(dot)com>
To: "Alvaro Herrera" <alvherre(at)commandprompt(dot)com>
Cc: "Bruce Momjian" <bruce(at)momjian(dot)us>, "Neil Conway" <neilc(at)samurai(dot)com>, "Trevor Hardcastle" <chizu(at)spicious(dot)com>, pgsql-patches(at)postgresql(dot)org
Subject: Re: CREATE TABLE LIKE INCLUDING INDEXES support
Date: 2007-05-23 10:54:29
Message-ID: d3c4af540705230354h7daf10ebhce40186b1f87abf9@mail.gmail.com (view raw or flat)
Thread:
Lists: pgsql-hackerspgsql-patches
Hi,

On 5/23/07, NikhilS <nikkhils(at)gmail(dot)com> wrote:
>
> Hi,
>
> > The index creation happens after the new table (which is LIKE the
> > parent) has been created, by appending the cxt.alist information to
> > "extras_after". The entry point for the index creation is thus via
> > ProcessUtility which expects an IndexStmt structure. That is why the current
> > patch does all the Oid to name mapping exercise to populate the relevant
> > fields in IndexStmt some of which are char pointers. The internal
> > DefineIndex function also expects most of the fields to be in IndexStmt like
> > format.
> >
> > If we want to follow the above suggestion, as I understand it, we might
> > have to devise a new structure to contain Oids and make ProcessUtility
> > accept a new nodeTag. We will also not be able to use existing Index
> > definition functions and this will lead to more coding IMHO. Do we want to
> > go down this path? Or is there something else that has been suggested above
> > and that I am missing completely?
>
>
> OTOH, we can populate a new structure with the relevant Oids, IndexInfo
> information from  parent relation indexes and call index_create directly
> from within ProcessUtility. Guess, it should be cleaner than the current
> approach.
>
Sorry for the barrage of emails. But as I looked closely at the current
patch there are only 2 fields  (accessMethod and tableSpace) in IndexStmt
structure that we populate by doing the conversion from OIDs to name. For
the other fields, the current transformations will remain.

If so, I think we can introduce 2 Oid fields in the IndexStmt structure and
store the Oids there. In DefineIndex we can use these Oids if they are not
invalid.

IMHO, all this is less work and the bulk of the changes remain localized in
mostly one or two functions as in the current patch.

Comments?

Regards,
Nikhils
-- 
EnterpriseDB               http://www.enterprisedb.com

In response to

Responses

pgsql-hackers by date

Next:From: Zdenek KotalaDate: 2007-05-23 12:32:00
Subject: Re: [GSOC] - I ntegrity check algorithm for data files
Previous:From: Hannes EderDate: 2007-05-23 07:59:06
Subject: msvc, build and install with cygwin in the PATH

pgsql-patches by date

Next:From: Alvaro HerreraDate: 2007-05-23 13:40:39
Subject: Re: CREATE TABLE LIKE INCLUDING INDEXES support
Previous:From: Hannes EderDate: 2007-05-23 07:59:06
Subject: msvc, build and install with cygwin in the PATH

Privacy Policy | About PostgreSQL
Copyright © 1996-2014 The PostgreSQL Global Development Group