On Mon, Jul 11, 2011 at 12:11 AM, Alvaro Herrera <alvhe...@commandprompt.com> wrote: > Excerpts from Robert Haas's message of dom jul 10 21:21:19 -0400 2011: >> On Jul 9, 2011, at 10:49 PM, Alvaro Herrera <alvhe...@commandprompt.com> >> wrote: >> > In short: in my opinion, attoptions and attfdwoptions need to be one >> > thing and the same. >> >> I feel the opposite. In particular, what happens when a future release of >> PostgreSQL adds an attoption that happens to have the same name as >> somebody's per-column FDW option? Something breaks, that's what... > > Hmm, if you follow my proposal above, that wouldn't actually happen, > because the core options do not apply to foreign columns.
Well, not at the moment. But I think it's altogether likely that we might want them to in the future. The foreign data wrapper support we have right now is basically a stub until we get around to improving it, so we don't (for example) analyze foreign tables, which means that n_distinct is not relevant. But that's something we presumably want to change at some point. Eventually, I would anticipate that we'll have quite a few more column options and most will apply to both tables and foreign tables, so I'm not keen to bake in something that makes that potentially problematic. I think we should understand attoptions as things that modify the behavior of PostgreSQL, while attfdw/genoptions are there solely for the foreign data wrapper to use. An extra nullable field in pg_attribute isn't costing us anything non-trivial, and the syntactic and definitional clarity seems entirely worth it. -- 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
