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

From NikhilS
Subject Re: CREATE TABLE LIKE INCLUDING INDEXES support
Date
Msg-id d3c4af540707100023te49748bi323b1d7ee5674e38@mail.gmail.com
Whole thread Raw
In response to Re: CREATE TABLE LIKE INCLUDING INDEXES support  (Neil Conway <neilc@samurai.com>)
Responses Re: CREATE TABLE LIKE INCLUDING INDEXES support
List pgsql-patches
Hi,

This version updates the patch to CVS HEAD and has various fixes and
refactoring, including proper docs. I refactored get_opclass_name() into
lsyscache.c, but then realized that this means that lsyscache.c will
depend on commands/indexcmds.c (for GetDefaultOpClass()), which is
arguably improper, so I'm tempted to revert and just duplicate the
syscache lookups in both ruleutils.c and parse_utilcmd.c

Yes, I too would vote for duplicating the  lookups for the sake of simplicity.

Nikhil: why are both "options" and "inhreloptions" necessary in
IndexStmt? Won't at least one be NULL?

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.

The challenge was with converting the stored reloptions belonging to the parent index into some form which could be consumed by transformRelOptions(). It was difficult to convert it into a list of DefElem entries and hence I had to introduce inhreloptions.

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

pgsql-patches by date:

Previous
From: Neil Conway
Date:
Subject: Re: CREATE TABLE LIKE INCLUDING INDEXES support
Next
From: Heikki Linnakangas
Date:
Subject: Re: Maintaining cluster order on insert