From: | Ron Snyder <snyder(at)roguewave(dot)com> |
---|---|
To: | 'Peter Eisentraut' <peter_e(at)gmx(dot)net> |
Cc: | pgsql-patches(at)postgresql(dot)org |
Subject: | Re: guc.c and postgresql.conf.sample constistency check |
Date: | 2002-06-07 23:05:48 |
Message-ID: | F888C30C3021D411B9DA00B0D0209BE803BB9A77@cvo-exchange.cvo.roguewave.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-patches |
>
> The catch is that some of these options (lc_*) are supposed
> to be absent,
> so it's not as easy as it seems.
Hmm. Are you saying that lc_* are being pulled out of code, so shouldn't be
in postgresql.conf.sample, or that they're staying in code but still
shouldn't be in postgresql.conf.sample?
According to guc.c, lc_* (except for lc_messages) are all PGC_USERSET, and
lc_messages is PGC_SUSET. Do those preclude the admin from setting defaults?
(Or is it that you don't want to suggest that they can be changed easily?
initdb wouldn't have to be to be re-run after changing the lc_* settings,
would it?)
Here's a bit from guc.h:
* SUSET options can be set at postmaster startup, with the SIGHUP
* mechanism, or from SQL if you're a superuser. These options cannot
* be set using the PGOPTIONS mechanism, because there is not check as
* to who does this.
*
* USERSET options can be set by anyone any time.
-ron (just trying to learn and contribute)
>
> --
> Peter Eisentraut peter_e(at)gmx(dot)net
>
From | Date | Subject | |
---|---|---|---|
Next Message | Joe Conway | 2002-06-07 23:11:20 | Re: [HACKERS] revised sample SRF C function; proposed SRF API |
Previous Message | Joe Conway | 2002-06-07 23:05:19 | Re: revised sample SRF C function; proposed SRF API |