Re: Inheritance, CREATE TABLE LIKE, and partitioned tables - Mailing list pgsql-hackers

From Bruce Momjian
Subject Re: Inheritance, CREATE TABLE LIKE, and partitioned tables
Date
Msg-id 200606270344.k5R3iJm22603@momjian.us
Whole thread Raw
In response to Inheritance, CREATE TABLE LIKE, and partitioned tables  (Greg Stark <gsstark@mit.edu>)
List pgsql-hackers
If you want to merge those functions, please do it as a separate patch
now that the patch has been applied.  Having too much unrelated stuff in
a patch does confuse things.

---------------------------------------------------------------------------

Greg Stark wrote:
> 
> Currently analyze.c and tablecmds.c both have some very similar code to handle
> copying columns from "parent" tables. As long as they were just copying
> columns and in the case of tablecmds.c copying check constraints that wasn't
> really that bad an idea, the code is pretty simple.
> 
> However with partitioned tables it becomes important to copy more table
> attributes like foreign key constraints and hopefully one day indexes. And it
> would be awfully convenient to have CREATE TABLE LIKE have options to copy the
> same things that inherited tables get. And have exactly the same semantics.
> 
> So I'm suggesting refactoring the code from analyze.c and tablecmds.c into
> functions to copy the columns, constraints, indexes etc.
> 
> For example I see a functions like:
> 
> List *CopyTableColumns(relation source, List *target_schema)
> List *CopyTableCheckConstraints(relation source, List *target_schema)
> ...
> 
> To do this though might require some changes in the algorithm used for
> inherited tables. Currently it builds up the list of merged columns
> incrementally. I'm thinking it would be more natural to accumulate all the
> columns from parents and then remove duplicates in a single pass. I think it
> should be possible to maintain precisely the same semantics doing this though.
> 
> I may be able to make AddInherits a consumer for these functions as well,
> though it would be a bit awkward since it would have to construct a fake list
> of ColumnDefs to act as the target schema. It would have the side effect of
> making the constraint comparison use change_varattnos_of_a_node and then
> compare the binary representations rather than decompiling the constraints to
> do the comparison. I'm not sure if that's the same semantics.
> 
> To a certain degree I feel like this is just make-work. The existing code
> works fine and I can just happily keep additing functionality to both
> analyze.c and tablecmds.c. And it's possible we won't always want to have the
> two match.
> 
> Has anyone looked at applying the ADD INHERITS patch yet? Would it be more or
> less likely to be accepted if it were a bigger patch that refactored all this
> stuff like I'm talking about?
> 
> -- 
> greg
> 
> 
> ---------------------------(end of broadcast)---------------------------
> TIP 5: don't forget to increase your free space map settings
> 

--  Bruce Momjian   bruce@momjian.us EnterpriseDB    http://www.enterprisedb.com
 + If your life is a hard drive, Christ can be your backup. +


pgsql-hackers by date:

Previous
From: Christopher Kings-Lynne
Date:
Subject: Re: GIN index creation extremely slow ?
Next
From: Bruce Momjian
Date:
Subject: Re: [COMMITTERS] pgsql: Disallow changing/dropping default expression