Re: Should enum GUCs be listed as such in config.sgml? - Mailing list pgsql-hackers

From Tom Lane
Subject Re: Should enum GUCs be listed as such in config.sgml?
Date
Msg-id 4416.1219509592@sss.pgh.pa.us
Whole thread Raw
In response to Re: Should enum GUCs be listed as such in config.sgml?  (Bruce Momjian <bruce@momjian.us>)
Responses Re: Should enum GUCs be listed as such in config.sgml?  (Magnus Hagander <magnus@hagander.net>)
Re: Should enum GUCs be listed as such in config.sgml?  (Magnus Hagander <magnus@hagander.net>)
List pgsql-hackers
Bruce Momjian <bruce@momjian.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


pgsql-hackers by date:

Previous
From: Tom Lane
Date:
Subject: Re: proposal sql: labeled function params
Next
From: Tom Lane
Date:
Subject: Re: [GENERAL] Surprising syntax error