On Tue, Feb 19, 2008 at 02:56:42PM +0100, Peter Eisentraut wrote:
> Am Dienstag, 19. Februar 2008 schrieb Magnus Hagander:
> > 1) Extend pg_settings with a column that contains an array of the available
> > options. Extend the config_string GUC struct with a hook that can return
> > this data.
>
> Before we get to the interface for reporting this to the client, I wonder how
> we should deal with this in the backend. Right now, we have string options
> with assign hooks. You'd need to add a reporting hook or something for each
> parameter. I'm thinking, perhaps we should invent a new GUC data type enum,
> now that enum is an accepted way to categorize with data around here. :)
> That could simplify the code a bit.
That would probably be a good idea - that one is in my scattered notes
about how to do it :-) I figured I'd start with the interface and then
proceed there later...
That would work for all the settings here I think, except for log_destinatino
which actually supports multiple choices from the enumeration. But that
would be fairly easy to implement on top of it.
So yes, I agree that creating an enum type for GUC would probably be a good
way to implement it. But I think trying to expose it as a SQL level enum is
not a good idea - just keeping it as a string there seems a lot better.
//Magnus
