From: | Magnus Hagander <magnus(at)hagander(dot)net> |
---|---|
To: | Peter Eisentraut <peter_e(at)gmx(dot)net> |
Cc: | pgsql-hackers(at)postgresql(dot)org |
Subject: | Re: Getting available options |
Date: | 2008-02-19 14:00:20 |
Message-ID: | 20080219140020.GM3091@svr2.hagander.net |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
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
From | Date | Subject | |
---|---|---|---|
Next Message | Gevik Babakhani | 2008-02-19 14:04:59 | Re: Getting available options |
Previous Message | Peter Eisentraut | 2008-02-19 13:56:42 | Re: Getting available options |