Re: Feature patch 1 for plperl [PATCH]
От | Tom Lane |
---|---|
Тема | Re: Feature patch 1 for plperl [PATCH] |
Дата | |
Msg-id | 4516.1263168347@sss.pgh.pa.us обсуждение исходный текст |
Ответ на | Re: Feature patch 1 for plperl [PATCH] (Andrew Dunstan <andrew@dunslane.net>) |
Список | pgsql-hackers |
Andrew Dunstan <andrew@dunslane.net> writes: > Tom Lane wrote: >> No, they have to all be PGC_POSTMASTER to answer that concern. Only >> breaking things for superusers isn't really that big an improvement >> over breaking them for everybody. > Well, I don't know about Tim but I think I could live with that. And > when we get some actual experience with using them we'll have a better > handle on whether or not it gives us any pain. Upon further review, PGC_POSTMASTER isn't going to work because of this in guc.c: /* * Only allow custom PGC_POSTMASTER variables to be created during shared * library preload; any later than that,we can't ensure that the value * doesn't change after startup. This is a fatal elog if it happens; just * erroringout isn't safe because we don't know what the calling loadable * module might already have hooked into. */ if (context == PGC_POSTMASTER && !process_shared_preload_libraries_in_progress) elog(FATAL, "cannot createPGC_POSTMASTER variables after startup"); We certainly don't want to make it such that plperl *has* to be preloaded, so PGC_POSTMASTER is out. However, I think PGC_SIGHUP would be enough to address my basic worry, which is that people shouldn't be depending on the ability to set these things within an individual session. regards, tom lane
В списке pgsql-hackers по дате отправления: