Thread: Shouldn't pg_settings.enumvals be array of text?
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?
regards, tom lane
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
Magnus Hagander <magnus@hagander.net> 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
Tom Lane wrote: > Magnus Hagander <magnus@hagander.net> 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 Herrera http://www.CommandPrompt.com/ PostgreSQL Replication, Consulting, Custom Development, 24x7 support
Alvaro Herrera wrote: > Tom Lane wrote: >> Magnus Hagander <magnus@hagander.net> 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
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 Herrera http://www.CommandPrompt.com/ The PostgreSQL Company - Command Prompt, Inc.
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 NOTsetting=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 gsmith@gregsmith.com http://www.gregsmith.com Baltimore, MD
Greg Smith <gsmith@gregsmith.com> 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
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 gsmith@gregsmith.com http://www.gregsmith.com Baltimore, MD
Tom Lane wrote: > Greg Smith <gsmith@gregsmith.com> 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
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 gsmith@gregsmith.com http://www.gregsmith.com Baltimore, MD
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
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 Herrera http://www.CommandPrompt.com/ The PostgreSQL Company - Command Prompt, Inc.
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 gsmith@gregsmith.com http://www.gregsmith.com Baltimore, MD