Re: CREATE FOREIGN TABLE ( ... LIKE ... ) - Mailing list pgsql-hackers

From Robert Haas
Subject Re: CREATE FOREIGN TABLE ( ... LIKE ... )
Date
Msg-id CA+TgmoYQ3bCuOW4Y5_x_zXh+5t3rCL9Ye4YpK_5rszw7wcR0Zg@mail.gmail.com
Whole thread Raw
In response to Re: CREATE FOREIGN TABLE ( ... LIKE ... )  (Andres Freund <andres@2ndquadrant.com>)
List pgsql-hackers
On Mon, Apr 7, 2014 at 4:24 PM, Andres Freund <andres@2ndquadrant.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.
> 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.

+1.

-- 
Robert Haas
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company



pgsql-hackers by date:

Previous
From: Robert Haas
Date:
Subject: Re: Doc typo in "9.28. Event Trigger Functions"
Next
From: Gregory Smith
Date:
Subject: Re: Pending 9.4 patches