Thread: Getting available options

Getting available options

From
Magnus Hagander
Date:
I'd like to add a way for a client (in this case, typicallyi pgadmin,
phppgadmin or similar) to get the available options on the server for the
GUC settings we have that take fixed options. This is to make it possible
to generate pretty dropdown lists of the options.

One way would be to simply pre-populate the client with the available
options. This sucks in at least two cases - the client has to be updated
whenever the server is. And, more importantly, in some cases the available
options depend on server-side build-time configuration (for example,
log_destination depends on win32/non win32 and syslog yes/no, wal_sync_method
depends on what's available on the OS).

In order to somehow get this data down from the client, I see a couple of
ways:

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.

2) Create a separate function, for the sake of argument
pg_get_available_options(<optionname>). Extend config_string GUC struct the
same way here.

3) Create one function for each of these, so a
pg_get_available_log_destinations(), pg_get_available_wal_sync_methods()
etc etc.

4) The best method available that I obviously didn't think of yet


Option 3 seems like an excessively ugly solution :) But what about the others?
What would people prefer?

//Magnus


Re: Getting available options

From
"Dave Page"
Date:
On Feb 19, 2008 1:22 PM, Magnus Hagander <magnus@hagander.net> wrote:
> I'd like to add a way for a client (in this case, typicallyi pgadmin,
> phppgadmin or similar) to get the available options on the server for the
> GUC settings we have that take fixed options. This is to make it possible
> to generate pretty dropdown lists of the options.
>
> One way would be to simply pre-populate the client with the available
> options. This sucks in at least two cases - the client has to be updated
> whenever the server is. And, more importantly, in some cases the available
> options depend on server-side build-time configuration (for example,
> log_destination depends on win32/non win32 and syslog yes/no, wal_sync_method
> depends on what's available on the OS).
>
> In order to somehow get this data down from the client, I see a couple of
> ways:
>
> 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.
>
> 2) Create a separate function, for the sake of argument
> pg_get_available_options(<optionname>). Extend config_string GUC struct the
> same way here.
>
> 3) Create one function for each of these, so a
> pg_get_available_log_destinations(), pg_get_available_wal_sync_methods()
> etc etc.
>
> 4) The best method available that I obviously didn't think of yet
>
>
> Option 3 seems like an excessively ugly solution :) But what about the others?
> What would people prefer?

I like option 1 the best. Minimally invasive, and probably easier to
handle on the client than 2. 3 is just ugly as you say. You should be
ashamed of yourself :-p

-- 
Dave Page
EnterpriseDB UK: http://www.enterprisedb.com
The Oracle-compatible database company


Re: Getting available options

From
Peter Eisentraut
Date:
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.

-- 
Peter Eisentraut
http://developer.postgresql.org/~petere/


Re: Getting available options

From
Magnus Hagander
Date:
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


Re: Getting available options

From
"Gevik Babakhani"
Date:
> I like option 1 the best. Minimally invasive, and probably 
> easier to handle on the client than 2. 

+1



Re: Getting available options

From
Alvaro Herrera
Date:
Magnus Hagander wrote:

> 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.

I think DateStyle should also be considered carefully, given how it has
two different settings in one variable (USE_XXX_STYLE and DATEORDER_XXX)

TimeZone would also be a little more difficult than an enum.

-- 
Alvaro Herrera                                http://www.CommandPrompt.com/
The PostgreSQL Company - Command Prompt, Inc.


Re: Getting available options

From
Magnus Hagander
Date:
On Tue, Feb 19, 2008 at 11:17:51AM -0300, Alvaro Herrera wrote:
> Magnus Hagander wrote:
> 
> > 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.
> 
> I think DateStyle should also be considered carefully, given how it has
> two different settings in one variable (USE_XXX_STYLE and DATEORDER_XXX)

Yeah, but you can turn those into enumerable combinations, no? (A,A; A,B;
B,A; B,B etc)


> TimeZone would also be a little more difficult than an enum.

Right, I didn't even have timezone under the enum list so far. Since
the list is just too long... For that one there is already a view available
to get all options, and you're likely to want to group them (for example,
by continent) anyway..

//Magnus


Re: Getting available options

From
Simon Riggs
Date:
On Tue, 2008-02-19 at 14:22 +0100, Magnus Hagander wrote:
> I'd like to add a way for a client (in this case, typicallyi pgadmin,
> phppgadmin or similar) to get the available options on the server for the
> GUC settings we have that take fixed options. This is to make it possible
> to generate pretty dropdown lists of the options.

How will this work with custom variable classes?

Seems fairly important not to diminish the extensibility of the server
by making those options more difficult to set.

--  Simon Riggs 2ndQuadrant  http://www.2ndQuadrant.com 



Re: Getting available options

From
Tom Lane
Date:
Simon Riggs <simon@2ndquadrant.com> writes:
> On Tue, 2008-02-19 at 14:22 +0100, Magnus Hagander wrote:
>> I'd like to add a way for a client (in this case, typicallyi pgadmin,
>> phppgadmin or similar) to get the available options on the server for the
>> GUC settings we have that take fixed options. This is to make it possible
>> to generate pretty dropdown lists of the options.

> How will this work with custom variable classes?

Anything like this will involve an API change in the guc stuff, so
that doesn't seem insurmountable.

I like the idea that was mentioned upthread of creating a new "enum"
category for GUC variables, instead of continuing to abuse the rather
inefficient "string" category for the purpose.  One reason is that
we then would not be faced with making an incompatible change in
the arguments of DefineCustomStringVariable.
        regards, tom lane


Re: Getting available options

From
Magnus Hagander
Date:
On Wed, Feb 20, 2008 at 05:59:27PM -0500, Tom Lane wrote:
> Simon Riggs <simon@2ndquadrant.com> writes:
> > On Tue, 2008-02-19 at 14:22 +0100, Magnus Hagander wrote:
> >> I'd like to add a way for a client (in this case, typicallyi pgadmin,
> >> phppgadmin or similar) to get the available options on the server for the
> >> GUC settings we have that take fixed options. This is to make it possible
> >> to generate pretty dropdown lists of the options.
> 
> > How will this work with custom variable classes?
> 
> Anything like this will involve an API change in the guc stuff, so
> that doesn't seem insurmountable.
> 
> I like the idea that was mentioned upthread of creating a new "enum"
> category for GUC variables, instead of continuing to abuse the rather
> inefficient "string" category for the purpose.  One reason is that
> we then would not be faced with making an incompatible change in
> the arguments of DefineCustomStringVariable.

Yeah, I liked that one as well - I'm going to look at doing that, and will
present some code as soon as I can to discuss the exact implementation. I
don't think it'll be too much work.

//Magnus


Re: Getting available options

From
Alvaro Herrera
Date:
Magnus Hagander wrote:

> > I like the idea that was mentioned upthread of creating a new "enum"
> > category for GUC variables, instead of continuing to abuse the rather
> > inefficient "string" category for the purpose.  One reason is that
> > we then would not be faced with making an incompatible change in
> > the arguments of DefineCustomStringVariable.
> 
> Yeah, I liked that one as well - I'm going to look at doing that, and will
> present some code as soon as I can to discuss the exact implementation. I
> don't think it'll be too much work.

It seems we have two clear proposal that had clear acceptance, and for
which we now need code: this enum stuff is one, and the other one is
the addition of "file origin" to pg_settings so that you can tell
what file a setting comes from (i.e. postgresql.conf or an included
file).

-- 
Alvaro Herrera                                http://www.CommandPrompt.com/
PostgreSQL Replication, Consulting, Custom Development, 24x7 support


Re: Getting available options

From
Magnus Hagander
Date:
On Thu, Feb 21, 2008 at 09:15:13AM -0300, Alvaro Herrera wrote:
> Magnus Hagander wrote:
> 
> > > I like the idea that was mentioned upthread of creating a new "enum"
> > > category for GUC variables, instead of continuing to abuse the rather
> > > inefficient "string" category for the purpose.  One reason is that
> > > we then would not be faced with making an incompatible change in
> > > the arguments of DefineCustomStringVariable.
> > 
> > Yeah, I liked that one as well - I'm going to look at doing that, and will
> > present some code as soon as I can to discuss the exact implementation. I
> > don't think it'll be too much work.
> 
> It seems we have two clear proposal that had clear acceptance, and for
> which we now need code: this enum stuff is one, and the other one is
> the addition of "file origin" to pg_settings so that you can tell
> what file a setting comes from (i.e. postgresql.conf or an included
> file).

Yes. And IMHO those are required befoer we can implement the stuff about
writing configuration variables in a good way. So they're now both high up
on my TODO list. If anybody wants to work on them, please talk to me first
so we don't dulpicate effort :-)

//Magnus