On Sat, Jan 4, 2014 at 11:07 AM, Fabrizio Mello <fabriziomello@gmail.com> wrote:
>> I continue to think that the case for having this feature at all has
>> not been well-made.
>
> We can use this feature to store any custom GUC for relations, attributes and functions also.
>
> Some use cases:
> * extension options
> * config for external apps (frameworks, third part software)
>
> Comments?
Well, as I said before, somebody can make their own configuration
table and store stuff there, rather than using pg_class.reloptions.
As I recall, the only response to that proposal was "well, they might
not want to do it that way", which does not strike me as a sufficient
reason.
What we've basically settled into for GUCs is that you can register a
custom GUC, but unless the module is loaded we'll accept any value for
that GUC without checking it. We'd presumably need a similar
mechanism here, or maybe you're proposing that we accept any reloption
at all with any associated value whatsoever, so long as the prefix is
ext. The first seems like an extension of an existing kludge of
which I'm not overly found, and the second is an even larger kludge.
In my experience as a software developer, there are very few places
where it's useful to accept and store user input without any
validation whatsoever, and I doubt that this is one of them.
--
Robert Haas
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company
