(2014/04/08 9:26), Michael Paquier wrote:
> On Tue, Apr 8, 2014 at 5:24 AM, 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.
> 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