| 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: | Whole Thread | Raw Message | 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 |