Re: [HACKERS] Shouldn't pg_settings.enumvals be array of text?
This is now the first entry on the new 8.4 Open Items list: http://wiki.postgresql.org/wiki/PostgreSQL_8.4_Open_Items -- * Greg Smith [EMAIL PROTECTED] http://www.gregsmith.com Baltimore, MD -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] Shouldn't pg_settings.enumvals be array of text?
Tom Lane wrote: Greg Smith [EMAIL PROTECTED] writes: When I was looking at this code for the first time recently I thought the same thing Tom did here--that this was kind of odd and it should give a text array back instead. I would even volunteer to take a stab at writing that change myself just to get some more practice with this section of code, should be able to squeeze that in over the next month. Fine with me, but let's be sure this doesn't slide off the radar screen. If we forget about it and release 8.4 with the current definition of the column, it'll be too late to change it. Might this be the time to add an open items for 8.4 page to the wiki? (I'm just assuming we'll do it on the wiki and not in Bruce's mailbox this time) I notice Greg put it on the project-specific wiki page around GUC, but we should probably collect these things at a central location as well.. If we want to do that, we should just ask our wiki-gurus to create some nice templates I think :-) //Magnus -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] Shouldn't pg_settings.enumvals be array of text?
On Tue, 7 Oct 2008, Magnus Hagander wrote: Might this be the time to add an open items for 8.4 page to the wiki? There's already: http://wiki.postgresql.org/wiki/Todo:WishlistFor84 Which was aimed at being a live version of that, but was superseded by the CommitFest pages. -- * Greg Smith [EMAIL PROTECTED] http://www.gregsmith.com Baltimore, MD -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] Shouldn't pg_settings.enumvals be array of text?
Greg Smith wrote: On Tue, 7 Oct 2008, Magnus Hagander wrote: Might this be the time to add an open items for 8.4 page to the wiki? There's already: http://wiki.postgresql.org/wiki/Todo:WishlistFor84 Which was aimed at being a live version of that, but was superseded by the CommitFest pages. wishlist != open items, IMHO. //Magnus -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] Shouldn't pg_settings.enumvals be array of text?
Greg Smith wrote: On Tue, 7 Oct 2008, Magnus Hagander wrote: Might this be the time to add an open items for 8.4 page to the wiki? There's already: http://wiki.postgresql.org/wiki/Todo:WishlistFor84 Which was aimed at being a live version of that, but was superseded by the CommitFest pages. No, open items is a list of tasks that must be completed before release, not a wishlist. Commitfest is not it either, because commitfest tracks submitted patches, whereas open items might not have a patch at all. -- Alvaro Herrerahttp://www.CommandPrompt.com/ The PostgreSQL Company - Command Prompt, Inc. -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] Shouldn't pg_settings.enumvals be array of text?
Tom Lane wrote: Currently, pg_settings.enumvals presents a list of strings formatted in an ad-hoc manner. Shouldn't we be presenting this as text[], so that clients don't need special-purpose code to break it apart? Another possible argument is that the values ought to be separated by newlines instead of , , which would still be a special-purpose format but it would probably look better in modern psql versions. At least it wouldn't be contributing to the problem of the view's output being ridiculously wide. Comments? Agreed, it can certainly be bettered. text[] seems to be the cleanest, but then we still have the issue with wide output in psql, no? But should we really design the view around the single use-case of psql? You can still just omit that column from the SELECT if you want... //Magnus -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] Shouldn't pg_settings.enumvals be array of text?
Magnus Hagander [EMAIL PROTECTED] writes: Agreed, it can certainly be bettered. text[] seems to be the cleanest, but then we still have the issue with wide output in psql, no? But should we really design the view around the single use-case of psql? You can still just omit that column from the SELECT if you want... Well, if we present as text[] then someone could easily use array_to_string to format the column the other way. So probably text[] is the right thing. regards, tom lane -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] Shouldn't pg_settings.enumvals be array of text?
Tom Lane wrote: Magnus Hagander [EMAIL PROTECTED] writes: Agreed, it can certainly be bettered. text[] seems to be the cleanest, but then we still have the issue with wide output in psql, no? But should we really design the view around the single use-case of psql? You can still just omit that column from the SELECT if you want... Well, if we present as text[] then someone could easily use array_to_string to format the column the other way. So probably text[] is the right thing. Let's have it as text[] and have psql apply array_to_string() over it. -- Alvaro Herrerahttp://www.CommandPrompt.com/ PostgreSQL Replication, Consulting, Custom Development, 24x7 support -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] Shouldn't pg_settings.enumvals be array of text?
Alvaro Herrera wrote: Tom Lane wrote: Magnus Hagander [EMAIL PROTECTED] writes: Agreed, it can certainly be bettered. text[] seems to be the cleanest, but then we still have the issue with wide output in psql, no? But should we really design the view around the single use-case of psql? You can still just omit that column from the SELECT if you want... Well, if we present as text[] then someone could easily use array_to_string to format the column the other way. So probably text[] is the right thing. Let's have it as text[] and have psql apply array_to_string() over it. Eh, how can psql do this? You access the view with a simple SELECT * FROM pg_settings, no? //Magnus -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] Shouldn't pg_settings.enumvals be array of text?
Magnus Hagander wrote: Alvaro Herrera wrote: Let's have it as text[] and have psql apply array_to_string() over it. Eh, how can psql do this? You access the view with a simple SELECT * FROM pg_settings, no? Hmm, I was thinking in some \-command ... -- Alvaro Herrerahttp://www.CommandPrompt.com/ The PostgreSQL Company - Command Prompt, Inc. -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] Shouldn't pg_settings.enumvals be array of text?
On Mon, 6 Oct 2008, Magnus Hagander wrote: Alvaro Herrera wrote: Let's have it as text[] and have psql apply array_to_string() over it. Eh, how can psql do this? You access the view with a simple SELECT * FROM pg_settings, no? The pg_settings view is a thin wrapper over what comes out of show_all_settings. Right now, to generate the enumvals field that does a call to config_enum_get_options to manually build a string out of the data. That's a pretty low-level chunk of code, basically doing s+=entry[record]+, for each non-hidden entry to build the string. When I was looking at this code for the first time recently I thought the same thing Tom did here--that this was kind of odd and it should give a text array back instead. I would even volunteer to take a stab at writing that change myself just to get some more practice with this section of code, should be able to squeeze that in over the next month. The fact that pg_settings was already way too wide even before the recent batch of additions is kind of a separate issue, and I don't think that doing some special case for the enumvals will be sufficient to make a dent in that problem. What I wanted to do once the additions settled down (which means next as of today) was update the documentation to suggest some neat ways you might use the information in pg_settings, like those I've been including as examples in recent messages. The queries there that were agreed to be useful might even turn into official subset views. Here's some examples of interesting subsets that do fit in my terminal session and what they might look like in view form: CREATE VIEW pg_settings_source AS SELECT name,setting,source,sourcefile,sourceline FROM pg_settings; CREATE VIEW pg_settings_modified AS SELECT name,current_setting(name),unit,setting,boot_val FROM pg_settings WHERE NOT setting=boot_val; CREATE VIEW pg_settings_session_changes AS SELECT name,setting,unit,reset_val FROM pg_settings WHERE NOT setting=reset_val; I'm torn on whether putting them into predefined views is really a good idea for a lot of reasons, including the fact that just putting them into the documentation (rather than in system_views.sql) helps popularize the idea that pg_settings is a useful interface admins can use to help manage their configurations. That's a helpful mindset for both the lots of installs to manage and can only reach the hosted server on port 5432 crowds. -- * Greg Smith [EMAIL PROTECTED] http://www.gregsmith.com Baltimore, MD -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] Shouldn't pg_settings.enumvals be array of text?
Greg Smith [EMAIL PROTECTED] writes: When I was looking at this code for the first time recently I thought the same thing Tom did here--that this was kind of odd and it should give a text array back instead. I would even volunteer to take a stab at writing that change myself just to get some more practice with this section of code, should be able to squeeze that in over the next month. Fine with me, but let's be sure this doesn't slide off the radar screen. If we forget about it and release 8.4 with the current definition of the column, it'll be too late to change it. regards, tom lane -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] Shouldn't pg_settings.enumvals be array of text?
On Mon, 6 Oct 2008, Tom Lane wrote: Fine with me, but let's be sure this doesn't slide off the radar screen. If we forget about it and release 8.4 with the current definition of the column, it'll be too late to change it. Agreed and understood. I hope to have some basic postgresql.conf tuning tools packaged by the time 8.4 is released, and everything needed to sort out the server-side of that is in my critical path for things that need to happen before November 1. text[] is my preferred format for some other things I'm working on, so anything that uses that for a list instead of a string I have to parse is a long-term win. -- * Greg Smith [EMAIL PROTECTED] http://www.gregsmith.com Baltimore, MD -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
