(2014/04/08 9:26), Michael Paquier wrote:
On Tue, Apr 8, 2014 at 5:24 AM, Andres Freund <and...@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.
This could be improved as well: it would be useful to be able to copy
the column options of another foreign table.
Yes, I think so, too. But to think of validating generic column/table
options, I think we would probably need to restrict LIKE to copy from
another foreign table maybe using the same FDW. So, I'd like to vote
for Tom's idea.
Thanks,
Best regards,
Etsuro Fujita
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
