Re: CREATE FOREIGN TABLE ( ... LIKE ... )

From: Michael Paquier <michael(dot)paquier(at)gmail(dot)com>
To: Andres Freund <andres(at)2ndquadrant(dot)com>
Cc: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>, David Fetter <david(at)fetter(dot)org>, Vik Fearing <vik(dot)fearing(at)dalibo(dot)com>, PG Hackers <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: CREATE FOREIGN TABLE ( ... LIKE ... )
Date: 2014-04-08 00:26:30
Message-ID: CAB7nPqRX-6P5+iy-mktnP_Mk0_ThVcCxseYcp1C+QFvSEgL8Nw@mail.gmail.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

On Tue, Apr 8, 2014 at 5:24 AM, Andres Freund <andres(at)2ndquadrant(dot)com> wrote:
> On 2014-04-05 11:46:16 -0400, Tom Lane wrote:
>> ISTM this is because the proposed feature is wrongheaded. The basic
>> concept of CREATE TABLE LIKE is that you're copying properties from
>> another object of the same type. You might or might not want every
>> property, but there's no question of whether you *could* copy every
>> property. In contrast, what this is proposing to do is copy properties
>> from (what might be) a plain table to a foreign table, and those things
>> aren't even remotely the same kind of object.
>>
>> It would make sense to me to restrict LIKE to copy from another foreign
>> table, and then there would be a different set of INCLUDING/EXCLUDING
>> options that would be relevant (options yes, indexes no, for example).
>
> I actually think it's quite useful to create a foreign table that's the
> same shape as a local table. And the patches approach of refusing to
> copy thinks that aren't supported sounds sane to me.
This could be improved as well: it would be useful to be able to copy
the column options of another foreign table.

> Consider e.g. moving off older partitioned data off to an archiving
> server. New local partitions are often created using CREATE TABLE LIKE,
> but that's not possible for the foreign ones.
Definitely a use case.
--
Michael

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Tom Lane 2014-04-08 01:47:38 Re: Why is it not sane to pass ExecStoreTuple(shouldFree=true) for tuples point into buffers
Previous Message Peter Geoghegan 2014-04-07 23:32:02 Re: B-Tree support function number 3 (strxfrm() optimization)