Re: [HACKERS] allowed user/db variables - Mailing list pgsql-patches

From Joe Conway
Subject Re: [HACKERS] allowed user/db variables
Date
Msg-id 3EFA47D6.5080509@joeconway.com
Whole thread Raw
In response to Re: [HACKERS] allowed user/db variables  (Tom Lane <tgl@sss.pgh.pa.us>)
Responses Re: [HACKERS] allowed user/db variables
List pgsql-patches
Tom Lane wrote:
> Joe Conway <mail@joeconway.com> writes:
>>Here is a patch to expand pg_settings. I included more than discussed
>>because it was easy and I thought it might be useful. Let me know if you
>>want some of them removed.
>
> Much of what you've included is part of the internal implementation of
> GUC, and I think it's unwise to expose it; any future changes in GUC
> might break the view (or more accurately break apps that are expecting
> the view to look a particular way).
>
> I agree with adding context, vartype, min_val, and max_val.  Not sure
> about boot_val or reset_val.  The RH guys do want to expose boot_val
> in their tool, since it's concerned with helping people set up
> postgresql.conf, but is it really useful for clients to see it?
> reset_val might be okay to expose ... not sure if we'd ever want to
> remove that concept from the implementation.

I thought you might say that. What about this list:

name
setting
context
vartype
source
min_val
max_val

ISTM that "source" is worth knowing.

>>name             | DateStyle
>>setting          | ISO with US (NonEuropean) conventions
>
> This reminds me, someone (Barry?) was griping that SHOW DATESTYLE
> doesn't produce a value that SET DATESTYLE will take.  Did we agree
> that it was OK to change the output to look like "ISO, US" etc?

I vaguely remember the thread:
http://archives.postgresql.org/pgsql-hackers/2003-05/msg00190.php

I don't see any followup (agreements or disagreements). Do you want me
to change that while I'm at it?

Joe


pgsql-patches by date:

Previous
From: Rod Taylor
Date:
Subject: Re: src/bin/psql/input.c
Next
From: Bruce Momjian
Date:
Subject: ecpg fix