Re: per-column generic option

(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);>