Michael Paquier <michael.paquier@gmail.com> writes:
> On Tue, Feb 18, 2014 at 7:22 AM, Andres Freund <andres@2ndquadrant.com> wrote:
>> Unless I miss something this possibly allows column definition to slip
>> by that shouldn't because normally all fdw column definitions are passed
>> through transformColumnDefinition() which does some checks, but the
>> copied ones aren't.
>> I haven't looked long enough to see whether that's currently
>> problematic, but even if not, it's sure a trap waiting to spring.
> transformColumnDefinition contains checks about serial and constraints
> mainly. The only thing that could be problematic IMO is the process
> done exclusively for foreign tables which is the creation of some
> ALTER FOREIGN TABLE ALTER COLUMN commands when per-column options are
> detected, something that is not passed to a like'd table with this
> patch. This may meritate a comment in the code.
> Actually after more thinking I think that it would make sense to have
> another INCLUDING/EXCLUDING option for foreign tables: OPTIONS to pass
> the column options when link is done from another foreign table. This
> should be another patch though.
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).
In any case, I agree with Andres' concern: whether or not it's a bug
currently that this bypasses some of the normal processing, it's a hazard
that can be expected to bite us someday.
regards, tom lane