Re: [PATCH] Store Extension Options

On Thu, Mar 13, 2014 at 11:30 AM, Alvaro Herrera
<alvherre@2ndquadrant.com> wrote:
> Robert Haas escribió:
>> Well, I don't have a big problem with the idea that some sessions
>> might not have a certain extension loaded.  For some extensions, that
>> might not lead to very coherent behavior, but I guess it's the
>> extension developer's job to tell the user whether or not that
>> extension needs shared_preload_libraries, needs either shared or local
>> preload_libraries, or can be installed however.  At the same time, I
>> don't feel compelled to provide an autoload mechanism to cover the
>> case where a user tries to set a label in a session which does not
>> have the label provider preloaded.  Such a mechanism will be complex
>> and introduce many problems of its own for what is in my mind a pretty
>> darn narrow benefit; and we sure as heck do not have time to engineer
>> it for 9.4.
>
> Eh?  Why do we need an autoload mechanism?  As far as I know, we already
> have one --- you call a function that's in an installed module, and if
> the module is not loaded, it will then be loaded.  So if we have a
> registry of validator functions, it will just be a matter of calling the
> validator function, and the autoloader will load the module.

We have an autoload mechanism for functions, but not for label
providers.  To make label providers autoload, we'd have to store them
in a catalog with pointers to pg_proc entries for their validators -
which seems like a can of worms, at least at this point in the release
cycle.

> Of course, the module needs to have been installed previously, but at
> least for extensions surely this is going to be the case.
>
> I don't really like the LABEL idea being proposed in this subthread to
> store options.  The nice thing about reloptions is that the code to
> parse input, validate the option names and values, and put the values in
> a struct is all already there.  All a module has to do is call a few
> appropriate functions and provide a "parsing table" that goes alongside
> a struct definition.  With LABELs, each module is going to have to
> provide code to do this all over, unless you're all thinking of
> something that I'm missing.

Well, I'm not sure that's really any big deal, but I'm not wedded to
the label idea.  My principal concern is: I'm opposed to allowing
unvalidated options into the database.  I think it should be a
requirement that if the validator can't be found and called, then the
reloption is no good and you just reject it.  So, if we go with the
reloptions route, I'd want to see pg_register_option_namespace go away
in favor of some solution that preserves that property.  One thing I
kind of like about the LABEL approach is that it applies to virtually
every object type, meaning that we might not have to repeat this
discussion when (as seems inevitable) people want to be able to do
things to schemas or tablespaces or roles.  But I don't hold that
position so strongly as to be unwilling to entertain any other
options.

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