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

From Andres Freund
Subject Re: CREATE FOREIGN TABLE ( ... LIKE ... )
Date
Msg-id 20140407202445.GN4161@awork2.anarazel.de
Whole thread Raw
In response to Re: CREATE FOREIGN TABLE ( ... LIKE ... )  (Tom Lane <tgl@sss.pgh.pa.us>)
Responses Re: CREATE FOREIGN TABLE ( ... LIKE ... )  (Michael Paquier <michael.paquier@gmail.com>)
Re: CREATE FOREIGN TABLE ( ... LIKE ... )  (Robert Haas <robertmhaas@gmail.com>)
List pgsql-hackers
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.

Greetings,

Andres Freund

-- Andres Freund                       http://www.2ndQuadrant.com/PostgreSQL Development, 24x7 Support, Training &
Services



pgsql-hackers by date:

Previous
From: Tom Lane
Date:
Subject: Re: B-Tree support function number 3 (strxfrm() optimization)
Next
From: Tom Lane
Date:
Subject: Re: Why is it not sane to pass ExecStoreTuple(shouldFree=true) for tuples point into buffers