Robert Haas <robertmhaas@gmail.com> writes:
> Looking at this a little more, I am inclined to think that
> ExtensionSetCVC() is entirely unacceptable. Our backend startup is
> high enough already. Sequential scanning the pg_extension catalog on
> every startup to spare the DBA the trouble of setting up
> postgresql.conf strikes me as a bad trade-off.
That seems like a reasonable viewpoint, but...
> If you were to come
> back and say that custom_variable_classes is a vile hack from the
> darkest reaches of wherever vile hacks originate from, I would agree
> with you. Having a GUC that controls what names can be used as GUCs
> is probably a bad design, and I'd like to come up with something
> better. But I don't think this is it.
... users IMO should not be concerned with custom_variable_classes at
all. The only users that know about it have already written an extension
in C. If some are using it in another context then even with my edits
they still can do so.
Now, for people following but not reading the patch, what's in is that
in order for extensions using custom_variable_classes to work without
the user having to care about it, I've added an step at backend startup
time to seqscan pg_extension and update custom_variable_classes from
this catalog.
When adding new entries to custom_variable_classes, known invalid
placeholders used to raise an error, that's no longer the case, we keep
them aside, as this comment in guc-file.l tells:
* 1. The class name is not valid according to the (new) setting * of custom_variable_classes. If so, we would reject,
butto * support custom_variable_classes being PGC_SUSET, we maintain * a list of not-yet-valid items. * * This list
willbe processed at assign_custom_variable_classes * time: each time cvc changes, we have candidates to * consider.
Sucha time is for example ExtensionSetCVC() from * backend post init, where we read additional cvc in * pg_extension
catalog.
Now, I can see this mechanism evolving in several directions. Either we
remove it entirely, or we add a list ok known custom_variable_classes
and SINVAL support for it so that as soon as the setting changes, all
concurrent backends know about it, and so that you have a catalog cache
to walk through rather than a real catalog to seqscan and backend init.
Other ideas?
--
Dimitri Fontaine
http://2ndQuadrant.fr PostgreSQL : Expertise, Formation et Support