Re: 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(at)hagander(dot)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(at)hagander(dot)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(at)hagander(dot)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 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 gsmith(at)gregsmith(dot)com http://www.gregsmith.com Baltimore, MD

Greg Smith <gsmith(at)gregsmith(dot)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(at)gregsmith(dot)com http://www.gregsmith.com Baltimore, MD

Tom Lane wrote:
> Greg Smith <gsmith(at)gregsmith(dot)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(at)gregsmith(dot)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.

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.

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

On Tue, 7 Oct 2008, Alvaro Herrera wrote:

> Greg Smith wrote:
>> http://wiki.postgresql.org/wiki/Todo:WishlistFor84
>
> No, "open items" is a list of tasks that must be completed before
> release, not a wishlist.

Moving this to a more appropriate list as not to bore all the hackers with
wiki minutia.

After a bit of research I realized the original Wishlist page and format,
which was quite active circa late 8.3, isn't really relevant anymore. I
just streamlined it to the parts that still make sense, which is just the
initial proposals (few of them actually executed anyway).

I was trying to avoid creating a new page just for open-items. On the
original developer's wiki, there was an expansion of special-purpose pages
for single tasks related to 8.3 that were really kind of confusing by the
end. I cleaned up a lot of that and would prefer not to go through that
again.

With that in mind, here's what I think makes sense:

-Rename "ToDo:WishlistFor84" to "Proposed 8.4 Projects" since that's what
it really ended up being. While not strictly necessary, it suggests how a
page like that should be named when the next release cycle starts, and
that old page title needs to get rid of the old ToDo: baggage anyway.

-Create a "PostgreSQL 8.4.0 Development Archive" that all the no longer
active pages can start moving to. The goal will be that ultimately it
will have *every* 8.4 page on it, as the main "Development Information"
page moves to tracking the next version. Push the page above
(Wishlist->Proposed) and GSoC pages onto there as initial no longer
mainstream content.

-Create a new "PostgreSQL 8.4 Release" page that tracks that process.
Populate it right now with the "Open Items" list. That gives a place to
put other final release-oriented notes at, since the CommitFest pages are
no longer going to be the place everything interesting is happening at.

I'm not sure whether that's the right title for the last page, part of why
I didn't just do all of the above already. But I think it's more
appropriate to create a page addressing the 8.4 release checklist, with
the coding "Open Items" just being the first section there, rather then
creating a page for every individual task. Maybe that's a better
name--"PostgreSQL 8.4 Checklist"?

Anyway, just wanted to start kicking around ideas for how to usefully
organize the end of the release cycle on the Wiki, which includes a bit of
thinking about how that will smoothly transition to the next release.

--
* Greg Smith gsmith(at)gregsmith(dot)com http://www.gregsmith.com Baltimore, MD

Greg Smith <gsmith(at)gregsmith(dot)com> writes:
> I was trying to avoid creating a new page just for open-items.

I'm not sure why not ...

The open-items list has been a major part of managing every previous
release cycle, and I'm sure it still will be when it's on the wiki
rather than posted to -hackers every so often. I don't think it's a
good idea to make it share a page with some unspecified set of other
stuff.

regards, tom lane

On Tue, 7 Oct 2008, Tom Lane wrote:

> Greg Smith <gsmith(at)gregsmith(dot)com> writes:
>> I was trying to avoid creating a new page just for open-items.
>
> I'm not sure why not ...

The reason I ask about stuff like this is to cut down the sheer number of
links that need to go on the high-level pages. Besides that just being
general good practice, it took quite a bit of shuffling to get
http://wiki.postgresql.org/wiki/Development_information and the pages
below it to be organized usefully. That page keeps getting trivial
content added to it, and it's already time for another round of trimming
that out so it's just the important stuff there at that top level of the
developer section.

> The open-items list has been a major part of managing every previous
> release cycle, and I'm sure it still will be when it's on the wiki

Fine; that clearly deserves its own page then and I'll hang myself on the
first hook there to get the ball rolling. Only reason I double-checked is
that I didn't want to see another created then ignored because it's not
relevant anymore page like the Wishlist. If you're sure that's still the
right way to organize this, you got it. I'll select some pages to evict
from their too prominant place to make space for it.

P.S. on this general topic: the growth in use of the CommitFest pages has
been interesting:

CommitFest 2008-03 (1,829 views)
CommitFest 2008-05 (4,103 views)
CommitFest 2008-07 (5,715 views)
CommitFest 2008-09 (6,048 views)

The 2008-11 one is already up to 1,276 views.

--
* Greg Smith gsmith(at)gregsmith(dot)com http://www.gregsmith.com Baltimore, MD

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(at)gregsmith(dot)com http://www.gregsmith.com Baltimore, MD