Robert Haas <robertmh...@gmail.com> writes:
> On Sun, Jul 17, 2011 at 12:59 AM, Tom Lane <t...@sss.pgh.pa.us> wrote:
>> I agree custom_variable_classes is conceptually messy, but it's a
>> reasonably lightweight compromise that gives some error checking without
>> requiring a lot of possibly-irrelevant extensions to be loaded into
>> every postgres process.
> Hmm. Maybe what we need is a mechanism that allows the configuration
> to be associated a loadable module, and whenever that module is
> loaded, we also load the associated configuration settings. This is
> probably terribly syntax, but something like:
> ALTER LOAD 'plpgsql' SET plpgsql.variable_conflict = 'whatever';
> AFAICS, that would remove the need to set variables in postgresql.conf
> that can't be validated, and so we could just disallow it.
No, that only fixes things for the case of setting a variable in the
control file. It isn't useful for ALTER ROLE/DATABASE SET. And it
still has the problem of forcing every process to load every extension,
and as written it would also require the postmaster to read catalogs.
> OTOH, maybe that's more trouble than can be justified by the size of
> the problem.
Yeah.
regards, tom lane
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
