Re: guc.c and postgresql.conf.sample constistency check - Mailing list pgsql-patches

From Ron Snyder
Subject Re: guc.c and postgresql.conf.sample constistency check
Date
Msg-id F888C30C3021D411B9DA00B0D0209BE803BB9A77@cvo-exchange.cvo.roguewave.com
Whole thread Raw
Responses Re: guc.c and postgresql.conf.sample constistency check  (Tom Lane <tgl@sss.pgh.pa.us>)
List 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@gmx.net
>

pgsql-patches by date:

Previous
From: snyder@snyder.dnsalias.org
Date:
Subject: documentation regarding postmaster boolean options
Next
From: Tom Lane
Date:
Subject: Re: guc.c and postgresql.conf.sample constistency check