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
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
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
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
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
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 , ,
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
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
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
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
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
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
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
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
14 matches
Mail list logo
