Re: Getting available options

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

In response to

Responses

Browse pgsql-hackers by date

  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