Re: Should enum GUCs be listed as such in config.sgml?

From: Magnus Hagander <magnus(at)hagander(dot)net>
To: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
Cc: Bruce Momjian <bruce(at)momjian(dot)us>, pgsql-hackers(at)postgresql(dot)org
Subject: Re: Should enum GUCs be listed as such in config.sgml?
Date: 2008-08-25 21:23:45
Message-ID: 48B322E1.2020508@hagander.net
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

Tom Lane wrote:
> 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...

Yes, it's on my TODO list waiting to bubble up to the top. Not forgotten
(yet).

//Magnus

In response to

Browse pgsql-hackers by date

  From Date Subject
Next Message Gregory Stark 2008-08-25 21:39:54 Re: Implementing cost limit/delays for insert/delete/update/select
Previous Message Grant Finnemore 2008-08-25 20:57:19 Proposal to sync SET ROLE and pg_stat_activity