(2014/01/31 9:56), Robert Haas wrote:
On Thu, Jan 30, 2014 at 5:05 PM, Tom Lane <t...@sss.pgh.pa.us> wrote:
Robert Haas <robertmh...@gmail.com> writes:
On Thu, Jan 30, 2014 at 11:04 AM, Tom Lane <t...@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
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
