(2014/01/31 9:56), Robert Haas wrote:
> On Thu, Jan 30, 2014 at 5:05 PM, Tom Lane <tgl@sss.pgh.pa.us> wrote:
>> Robert Haas <robertmhaas@gmail.com> writes:
>>> On Thu, Jan 30, 2014 at 11:04 AM, Tom Lane <tgl@sss.pgh.pa.us> wrote:
>>>> I think this is totally misguided. Who's to say that some weird FDW
>>>> might not pay attention to attstorage? I could imagine a file-based
>>>> FDW using that to decide whether to compress columns, for instance.
>>>> Admittedly, the chances of that aren't large, but it's pretty hard
>>>> to argue that going out of our way to prevent it is a useful activity.
>>
>>> I think that's a pretty tenuous position. There are already
>>> FDW-specific options sufficient to let a particular FDW store whatever
>>> kinds of options it likes; letting the user set options that were only
>>> ever intended to be applied to tables just because we can seems sort
>>> of dubious. I'm tempted by the idea of continuing to disallow SET
>>> STORAGE on an unvarnished foreign table, but allowing it on an
>>> inheritance hierarchy that contains at least one real table, with the
>>> semantics that we quietly ignore the foreign tables and apply the
>>> operation to the plain tables.
>>
>> [ shrug... ] By far the easiest implementation of that is just to apply
>> the catalog change to all of them. According to your assumptions, it'll
>> be a no-op on the foreign tables anyway.
>
> Well, there's some point to that, too, I suppose. What do others think?
Allowing ALTER COLUMN SET STORAGE on foreign tables would make sense if
for example, "SELECT * INTO local_table FROM foreign_table" did create a
new local table of columns having the storage types associated with
those of a foreign table?
Thanks,
Best regards,
Etsuro Fujita
