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

Re: Copy storage parameters on CREATE TABLE LIKE/INHERITS

From: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
To: daveg <daveg(at)sonic(dot)net>
Cc: ITAGAKI Takahiro <itagaki(dot)takahiro(at)oss(dot)ntt(dot)co(dot)jp>, pgsql-hackers(at)postgresql(dot)org
Subject: Re: Copy storage parameters on CREATE TABLE LIKE/INHERITS
Date: 2008-07-30 23:27:11
Message-ID: (view raw, whole thread or download thread mbox)
Lists: pgsql-hackers
daveg <daveg(at)sonic(dot)net> writes:
> On Wed, Jul 30, 2008 at 04:45:47PM +0900, ITAGAKI Takahiro wrote:
>> Here is a patch to copy column storage parameters and reloptions on
>> CREATE TABLE LIKE, which I proposed at:

> I'd like to have the ability to copy these parameters, but not to have it
> be automatic.

There are a couple of other things that need to be thought about:

* LIKE is intended to copy a table as a *portion* of another table;
for example it adds the source table's columns to whatever was specified
directly in CREATE TABLE, plus possibly other LIKE invocations.  For

regression=# create table t1 (f1 int);
regression=# create table t2 (f2 text);
regression=# create table t3 (f3 float, like t1, like t2);
regression=# \d t3
           Table "public.t3"
 Column |       Type       | Modifiers 
 f3     | double precision | 
 f1     | integer          | 
 f2     | text             | 

I think therefore that having LIKE copy anything "global" to a table,
such as tablespace or reloptions, is fundamentally wrongheaded.  What
will you do about conflicts?  The same is true for inheritance cases,
since a table can inherit from multiple parents.

* LIKE INCLUDING INDEXES, on the other hand, copies indexes as units,
so it's sensible that it should (and already does) copy the tablespace
and reloptions of those indexes.  This leads to a disconnect between
the table-level and index-level behavior, which I believe is what is
bothering Itagaki-san.  I'm not sure what to do about it but making
them behave the same is not necessarily a good answer.

* It does make sense to copy per-column storage parameters, if you
consider those as part of the column definitions.  However, I'm not
clear on how we'd "merge" storage parameters when the same column
appears from multiple parents.

			regards, tom lane

In response to


pgsql-hackers by date

Next:From: Henry B. HotzDate: 2008-07-31 02:15:54
Subject: Re: Plans for 8.4
Previous:From: Tom LaneDate: 2008-07-30 23:11:50
Subject: Re: printing raw parse tree

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