Re: Extensions, patch v20 (bitrot fixes) (was: Extensions, patch v19 (encoding brainfart fix))
От | Robert Haas |
---|---|
Тема | Re: Extensions, patch v20 (bitrot fixes) (was: Extensions, patch v19 (encoding brainfart fix)) |
Дата | |
Msg-id | AANLkTikVsyxVt=XYER01i=QpSTe0t6C3VKKGsy9hSQ4i@mail.gmail.com обсуждение исходный текст |
Ответ на | Re: Extensions, patch v20 (bitrot fixes) (was: Extensions, patch v19 (encoding brainfart fix)) (Robert Haas <robertmhaas@gmail.com>) |
Ответы |
Extensions and custom_variable_classes (was: Extensions, patch v20 (bitrot fixes))
|
Список | pgsql-hackers |
On Sat, Dec 18, 2010 at 10:04 PM, Robert Haas <robertmhaas@gmail.com> wrote: > - Has the issue of changing custom_variable_classes from PGC_SIGHUP to > PGC_SUSET been discussed? I am not sure whether that's an OK thing to > do. If it is OK, then the documentation also needs updating. > > - This comment looks like leftovers: > > + /* FIXME: add PGC_EXTENSION so that we don't abuse PGC_SIGHUP here? */ > + SetConfigOption("custom_variable_classes", > + newval, PGC_SIGHUP, PGC_S_EXTENSION); > > Apologies if I missed the previous discussion of this, but why are we > adding a new GUC context? 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. 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. -- Robert Haas EnterpriseDB: http://www.enterprisedb.com The Enterprise PostgreSQL Company
В списке pgsql-hackers по дате отправления: