Re: Inheritance, CREATE TABLE LIKE, and partitioned tables

From: Bruce Momjian <bruce(at)momjian(dot)us>
To: Greg Stark <gsstark(at)mit(dot)edu>
Cc: pgsql-hackers(at)postgresql(dot)org
Subject: Re: Inheritance, CREATE TABLE LIKE, and partitioned tables
Date: 2006-06-27 03:44:19
Message-ID: 200606270344.k5R3iJm22603@momjian.us
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: 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(at)momjian(dot)us
EnterpriseDB http://www.enterprisedb.com

+ If your life is a hard drive, Christ can be your backup. +

In response to

Browse pgsql-hackers by date

  From Date Subject
Next Message Alvaro Herrera 2006-06-27 03:45:16 pgsql: Clamp last_anl_tuples to n_live_tuples, in case we vacuum a table
Previous Message Tom Lane 2006-06-27 03:37:30 Re: [HACKERS] PQescapeIdentifier