Re: Add support for logging the current role - Mailing list pgsql-hackers

From Stephen Frost
Subject Re: Add support for logging the current role
Date
Msg-id 20110115032039.GZ4933@tamriel.snowman.net
Whole thread Raw
In response to Re: Add support for logging the current role  (Tom Lane <tgl@sss.pgh.pa.us>)
Responses Re: Add support for logging the current role  (Tom Lane <tgl@sss.pgh.pa.us>)
List pgsql-hackers
* Tom Lane (tgl@sss.pgh.pa.us) wrote:
> everything that looks at this GUC value
> will know instantly what it is for each version.
> The last bit is kind of a killer for tools like pgfouine, no?

Ugh..  Could we just accept it as input but return the full list if
asked for it>

> In any case I thought the
> expectation here was that the default column list would be frozen at
> what it is now, and probably will never change.

This I don't like..  When I install a new version fresh, I like to get
all of the "bells & whistles" that go along with it, which, in my view,
would include new fields that the smart PG folks have decided might be
useful for me.  I'd like to provide a way for users who are upgrading to
be able to get the old behavior back, to minimize the trouble for them,
and being able to say "just change the version_9_1 to version_9_0 in
your log_csv_fields GUC" is a heck of a lot better than "well, rip out
the default and replace it with this huge list of fields".

I'd been puzzling over how to deal with this big list of fields in
postgresql.conf and I do like the idea of some kind of short-cut being
provided to ease the pain for users.  What about something other than
version_x_y?  I could maybe see having a 'default' and an 'all'
instead..  Then have the default be what we have currently and 'all' be
the full list I'm thinking about.
Thanks,
    Stephen

pgsql-hackers by date:

Previous
From: Tom Lane
Date:
Subject: Re: Add support for logging the current role
Next
From: Stephen Frost
Date:
Subject: Re: Add support for logging the current role