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

Inheritance, CREATE TABLE LIKE, and partitioned tables

From: Greg Stark <gsstark(at)mit(dot)edu>
To: pgsql-hackers(at)postgresql(dot)org
Subject: Inheritance, CREATE TABLE LIKE, and partitioned tables
Date: 2006-06-26 16:31:24
Message-ID: 874py7yj37.fsf@stark.xeocode.com (view raw or flat)
Thread:
Lists: pgsql-hackers
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


Responses

pgsql-hackers by date

Next:From: Bruce MomjianDate: 2006-06-26 16:40:53
Subject: Re: Overhead for stats_command_string et al, take 2
Previous:From: Bruce MomjianDate: 2006-06-26 16:21:01
Subject: Re: vacuum, performance, and MVCC

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