| From: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> | 
|---|---|
| To: | Peter Eisentraut <peter_e(at)gmx(dot)net> | 
| Cc: | pgsql-hackers(at)postgresql(dot)org | 
| Subject: | Re: GUC with units, details | 
| Date: | 2006-07-26 13:44:08 | 
| Message-ID: | 1306.1153921448@sss.pgh.pa.us | 
| Views: | Whole Thread | Raw Message | Download mbox | Resend email | 
| Thread: | |
| Lists: | pgsql-hackers | 
Peter Eisentraut <peter_e(at)gmx(dot)net> writes:
> Tom Lane wrote:
>> That seems OK for SHOW, which is mainly intended for human
>> consumption, but what will you do with pg_settings?  For programmatic
>> use I think we want more predictable behavior.
> I'd think that a program would not care.  Or do you want a units-free 
> display that can be parsed as integer?
Yeah.  If the value might be shown as either "99kB" or "9MB" then a
program *must* have a pretty complete understanding of the units system
to make sense of it at all.  Furthermore this is not backwards
compatible --- it'll break any existing code that inspects pg_settings
values.  I suggest that the values column should continue to display
exactly as it does today (ie, the integer value in the var's native
units) and we just add a column saying what the native units are.
> Do we want to introduce a difference between pg_settings and SHOW ALL?
Yup, I think that's the lesser of the evils.
regards, tom lane
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Tom Lane | 2006-07-26 13:58:19 | Re: Resurrecting per-page cleaner for btree | 
| Previous Message | Jonah H. Harris | 2006-07-26 12:04:58 | Re: INSERT ... RETURNING in 8.2 |