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? -- 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
