Обсуждение: Getting available options
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
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
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/
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
> I like option 1 the best. Minimally invasive, and probably > easier to handle on the client than 2. +1
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.
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
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
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
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
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
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