Re: guc.c and postgresql.conf.sample constistency check

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
>

Responses

Browse pgsql-patches by date

  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