On Thu, Jan 30, 2014 at 11:04 AM, Tom Lane <t...@sss.pgh.pa.us> wrote: > Shigeru Hanada <shigeru.han...@gmail.com> writes: >> At the moment we don't use attstorage for foreign tables, so allowing >> SET STORAGE against foreign tables never introduce visible change >> except \d+ output of foreign tables. But IMO such operation should >> not allowed because users would be confused. So I changed >> ATExecSetStorage() to skip on foreign tables. > > 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. -- Robert Haas EnterpriseDB: http://www.enterprisedb.com The Enterprise PostgreSQL Company -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
