(2011/07/15 4:17), Josh Berkus wrote: > All, > > Is the spec for this feature still under discussion? I don't seem to > see a consensus on this thread.
Yeah, a remaining concern is whether generic (FDW) options should be separated from existing attoptions or not. Indeed, reloptions/attoptions mechanism seems to be also applicable to generic options, since both need to store multiple key-value pairs, but IMHO generic options should be separated from reloptions/attoptions for several reasons: 1) FDW options are handled by only FDW, but reloptions/attoptions are handled by PG core modules such as planner, AM and autovacuum. If we can separate them completely, they would be able to share one attribute, but I worry that some of reloptions/attoptions make sense for some FDW. For instance, n_distinct might be useful to control costs of a foreign table scan. Though attoptions can't be set via CREATE/ALTER FOREIGN TABLE yet. 2) In future, newly added option might conflict somebody's FDW option. Robert Haas has pointed out this issue some days ago. FDW validator would reject unknown options, so every FDW would have to know all of reloptions/attoptions to avoid this issue. 3) It would be difficult to unify syntax to set options from perspective of backward compatibility and syntax consistency. Other SQL/MED objects have the syntax such as "OPTIONS (key 'value', ...)", but reloptions/attoptions have the syntax such as "SET (key = value, ...)". Without syntax unification, some tools should care relkind before handling attoptions. For instance, pg_dump should choose syntax used to dump attoptions. It seems undesired complexity. Any comments/objections/questions are welcome. Regards, -- Shigeru Hanada * 英語 - 自動検出 * 英語 * 日本語 * 英語 * 日本語 <javascript:void(0);> -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
