From: | Alvaro Herrera <alvherre(at)2ndquadrant(dot)com> |
---|---|
To: | Robert Haas <robertmhaas(at)gmail(dot)com> |
Cc: | Andres Freund <andres(at)2ndquadrant(dot)com>, Simon Riggs <simon(at)2ndquadrant(dot)com>, Fabrízio de Royes Mello <fabriziomello(at)gmail(dot)com>, Abhijit Menon-Sen <ams(at)2ndquadrant(dot)com>, Peter Eisentraut <peter_e(at)gmx(dot)net>, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>, Pavel Stehule <pavel(dot)stehule(at)gmail(dot)com>, Pgsql Hackers <pgsql-hackers(at)postgresql(dot)org> |
Subject: | Re: [PATCH] Store Extension Options |
Date: | 2014-03-13 15:30:23 |
Message-ID: | 20140313153023.GH4744@eldon.alvh.no-ip.org |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
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.
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.
--
Álvaro Herrera http://www.2ndQuadrant.com/
PostgreSQL Development, 24x7 Support, Training & Services
From | Date | Subject | |
---|---|---|---|
Next Message | Andres Freund | 2014-03-13 15:37:13 | Re: [PATCH] Store Extension Options |
Previous Message | Robert Haas | 2014-03-13 15:28:33 | Re: pg_archivecleanup bug |