Re: per-column generic option

On Mon, Jul 18, 2011 at 3:26 PM, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> wrote:
> Robert Haas <robertmhaas(at)gmail(dot)com> writes:
>> ... 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.
>
> +1.  We paid the price of allowing nullable columns in pg_attribute long
> ago.  One more isn't going to cost anything, especially since virtually
> every row in that catalog already contains at least one null.
>
> I'm not too thrilled with the terminology of "generic options", though.
> I think this should be understood as specifically "FDW-owned options".
> If the column isn't reserved for the use of the FDW, then you get right
> back into the problem of who's allowed to use it and what if there's a
> collision.

I concur. The SQL/MED standard is welcome to refer to them as generic
options, but at least FTTB they are going to be entirely for FDWs in
our implementation, and naming them that way is therefore a Good
Thing. If the SQL committee decides to use them in other places and
we choose to support that in some future release for some
as-yet-unclear purpose, well, it won't be the first time we've
modified the system catalog schema.

--
Robert Haas
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company