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

Re: Copy storage parameters on CREATE TABLE LIKE/INHERITS

From: ITAGAKI Takahiro <itagaki(dot)takahiro(at)oss(dot)ntt(dot)co(dot)jp>
To: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
Cc: daveg <daveg(at)sonic(dot)net>, pgsql-hackers(at)postgresql(dot)org
Subject: Re: Copy storage parameters on CREATE TABLE LIKE/INHERITS
Date: 2008-08-01 02:53:25
Message-ID: (view raw, whole thread or download thread mbox)
Lists: pgsql-hackers
Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> wrote:

> 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;

You're absolutely right. I just thought it's a *better default* behavior
because LIKE and INHERITS are often used in single inheritance, but
in definition they declare columns, not whole tables.
In other words, we don't have an ability of copying tables as units...

However, I think we'd better to have an ability to copy reloptions easily.
There were requests about adding a configuration parameter to modify 
default fillfactor. I think reloption-cloning would be a solution about it.

How about adding a new WITH-LIKE syntax?

 CREATE TABLE newtbl ( ... ) WITH (LIKE "template-table")

It is expanded to an option array as below:

 SELECT 'WITH (' || array_to_string(
          array_append(reloptions, 'OIDS=' || relhasoids), ',') || ')'
   FROM pg_class
  WHERE oid = "template-table";

> 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.

Currently I uses the first setting found in multiple tables
and directly specified options have the highest priority.
For example, setting are used in order of [A] -> [B] -> [C].
Conflicted parameters are ignored silently for now.

  CREATE TABLE newtbl (LIKE [B], LIKE [C]) WITH ([A])

ITAGAKI Takahiro
NTT Open Source Software Center

In response to

pgsql-hackers by date

Next:From: Robert LorDate: 2008-08-01 04:08:56
Subject: Re: Review: DTrace probes (merged version) ver_03
Previous:From: Tom LaneDate: 2008-08-01 00:54:49
Subject: Fixing the representation of ORDER BY/GROUP BY/DISTINCT

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