From: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
---|---|
To: | Bruce Momjian <bruce(at)momjian(dot)us> |
Cc: | pgsql-hackers(at)postgresql(dot)org, Magnus Hagander <magnus(at)hagander(dot)net> |
Subject: | Re: Should enum GUCs be listed as such in config.sgml? |
Date: | 2008-08-23 16:39:52 |
Message-ID: | 4416.1219509592@sss.pgh.pa.us |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
Bruce Momjian <bruce(at)momjian(dot)us> writes:
> bruce wrote:
>> Tom Lane wrote:
>>> Currently, config.sgml still describes the new "enum" GUC variables
>>> as being of type "string" --- but pg_settings says they are "enum".
>>> This is not very consistent, but I wonder whether changing the docs
>>> would be more confusing or less so. I note that section 18.1 doesn't
>>> mention the enum alternative either.
>>
>> I looked into this and I think the documentation is fine. If enums
>> didn't require quotes but strings did, we would document them
>> differently, but the fact is that enums are the same as strings except
>> enums have a limited number of possible values --- that isn't something
>> that is usually identified in a variable type definition heading.
By that logic, we should not distinguish integers and floats. One's
just a restricted form of the other.
> Looking further, it seems we still have an inconsistency problem because
> pg_settings mentions enum; should we just change that to 'string'?
No, and in fact pg_settings is the counterexample to your conclusion
that it's okay to pretend enums are the same as strings: since it has an
enumvals column that's populated for enums and not for strings, there
is clearly a genuine user-visible difference.
Last I checked, Magnus had promised to come up with suitable
documentation changes for this patch, but then he went off sailing...
regards, tom lane
From | Date | Subject | |
---|---|---|---|
Next Message | Andrew Dunstan | 2008-08-23 18:42:57 | Re: Proposal: new border setting in psql |
Previous Message | Tom Lane | 2008-08-23 16:15:05 | Re: proposal sql: labeled function params |