Folks,

Last we talked (before the mail server went down) Tom had agreed in principle 
to a re-ordering of postgresql.conf.sample and the "Run-Time Configuration" 
docs page based on the attached ordering file.

I would like to make this happen before feature-freeze on June 15.   To do 
that, I need more info:

1) Are any additional changes expected for GUC.c before feature-freeze?

2) Are all of the new GUC.c variables for 7.4 already documented in the CVS 
docs?  If not, can the responsible parties send me descriptions so that I can 
doc it?

3) Do people want me to take a stab at re-ordering GUC.c as well (that is, 
Tom's idea of having the GUC.c ordering alphabetical within each variable 
type), considering that I am not a C programmer?

4) Does anyone else have any comments on the proposed re-ordering?

-- 
Josh Berkus
Aglio Database Solutions
San Francisco
Thu, 5 Jun 2003 08:23:47 -0700
Josh Berkus <josh@agliodbs.com>
Proposal to Re-Order Postgresql.Conf, part II
> 4) Does anyone else have any comments on the proposed re-ordering?

Since we're painting a shed, does it make sense to put the items in
alphabetical order for each section?

-- 
Rod Taylor <rbt@rbt.ca>

PGP Key: http://www.rbt.ca/rbtpub.asc
05 Jun 2003 13:29:31 -0400
Rod Taylor <rbt@rbt.ca>
Re: Proposal to Re-Order Postgresql.Conf, part II
Rod,

> > 4) Does anyone else have any comments on the proposed re-ordering?
> 
> Since we're painting a shed, does it make sense to put the items in
> alphabetical order for each section?

I thought about that, yes.   However, I find that most items have a logical 
order that is not alphabetical.   Take the WAL section for example:

"fsync" needs to go first, because if it is set to "false" the rest of the WAL 
settings don't matter.

"wal_sync_method" and "wal_buffers" are the "most important" (or, at least, 
most likely to be tinkered with) settings so they sould go immdiately after.

"checkpoint_segments, checkpoint_timeout, commit_delay, commit_siblings" are 
all directly related and should to appear in that order (which, oddly enough, 
happens to be alphabetical).

"wal_debug" is seldom used outside of Postgresql source development or unusual 
system failures, and should therefore go last.

I have tried to order other parameters by applying the same logic, which 
essentially amounts to:  order by most important/most likely to be changed, 
grouping settings that need to be manipulated together.   I'd be happy to 
hear your comments on my application of that logic.

BTW, everyone:  I do not seem to be receiving any Postgresql.org mail since 
the server crash & restoration.  So please cc: any comments directly to me!

-- 
-Josh Berkus
 Aglio Database Solutions
 San Francisco


Thu, 5 Jun 2003 11:16:53 -0700
Josh Berkus <josh@agliodbs.com>
Re: Proposal to Re-Order Postgresql.Conf, part II
On Thu, 2003-06-05 at 14:16, Josh Berkus wrote:
> Rod,
> 
> > > 4) Does anyone else have any comments on the proposed re-ordering?
> > 
> > Since we're painting a shed, does it make sense to put the items in
> > alphabetical order for each section?
> 
> I thought about that, yes.   However, I find that most items have a logical 
> order that is not alphabetical.   Take the WAL section for example:

Excellent point.

> BTW, everyone:  I do not seem to be receiving any Postgresql.org mail since 
> the server crash & restoration.  So please cc: any comments directly to me!

You re-subscribed I assume...

-- 
Rod Taylor <rbt@rbt.ca>

PGP Key: http://www.rbt.ca/rbtpub.asc
05 Jun 2003 14:39:36 -0400
Rod Taylor <rbt@rbt.ca>
Re: Proposal to Re-Order Postgresql.Conf, part II
Josh Berkus <josh@agliodbs.com> writes:
> 1) Are any additional changes expected for GUC.c before feature-freeze?

I'm still thinking of adding an am_superuser variable so that psql can
rely on the new ParameterStatus mechanism instead of explicit queries to
find out if you're superuser.  But this would be a read-only variable
and so should not appear in postgresql.conf.  Offhand I'm not aware of
any other proposed additions ... but something might turn up.

> 2) Are all of the new GUC.c variables for 7.4 already documented in the CVS 
> docs?

They should be.

			regards, tom lane

Fri, 06 Jun 2003 11:29:58 -0400
Tom Lane <tgl@sss.pgh.pa.us>
Re: Proposal to Re-Order Postgresql.Conf, part II 
On Thu, 2003-06-05 at 11:23, Josh Berkus wrote:
> 
> 4) Does anyone else have any comments on the proposed re-ordering?
> 

I think this was touched on before, but was there a final determination
of the ordering of the "show all" command? I'm hoping that will return
in the new order of the postgresql.conf

Robert Treat
-- 
Build A Brighter Lamp :: Linux Apache {middleware} PostgreSQL


06 Jun 2003 16:30:54 -0400
Robert Treat <xzilla@users.sourceforge.net>
Re: Proposal to Re-Order Postgresql.Conf, part II
Robert Treat <xzilla@users.sourceforge.net> writes:
> I think this was touched on before, but was there a final determination
> of the ordering of the "show all" command?

SHOW ALL will remain alphabetical.

			regards, tom lane

Sat, 07 Jun 2003 11:27:02 -0400
Tom Lane <tgl@sss.pgh.pa.us>
Re: Proposal to Re-Order Postgresql.Conf, part II 

I think people thought if you were doing SHOW ALL, you were looking for
a specific variable, so alphabetical was best.

---------------------------------------------------------------------------

Robert Treat wrote:
> On Thu, 2003-06-05 at 11:23, Josh Berkus wrote:
> > 
> > 4) Does anyone else have any comments on the proposed re-ordering?
> > 
> 
> I think this was touched on before, but was there a final determination
> of the ordering of the "show all" command? I'm hoping that will return
> in the new order of the postgresql.conf
> 
> Robert Treat
> -- 
> Build A Brighter Lamp :: Linux Apache {middleware} PostgreSQL
> 
> 
> ---------------------------(end of broadcast)---------------------------
> TIP 6: Have you searched our list archives?
> 
> http://archives.postgresql.org
> 

-- 
  Bruce Momjian                        |  http://candle.pha.pa.us
  pgman@candle.pha.pa.us               |  (610) 359-1001
  +  If your life is a hard drive,     |  13 Roberts Road
  +  Christ can be your backup.        |  Newtown Square, Pennsylvania 19073

Sat, 7 Jun 2003 12:33:10 -0400 (EDT)
Bruce Momjian <pgman@candle.pha.pa.us>
Re: Proposal to Re-Order Postgresql.Conf, part II
Josh Berkus <josh@agliodbs.com> writes:
> "wal_debug" is seldom used outside of Postgresql source development or unusual 
> system failures, and should therefore go last.

BTW, it occurs to me that wal_debug is one of the hacker-only variables
that probably ought not be documented at all.  I cannot imagine any use
for it for the average DBA.

			regards, tom lane

Sun, 08 Jun 2003 11:38:42 -0400
Tom Lane <tgl@sss.pgh.pa.us>
Re: Proposal to Re-Order Postgresql.Conf, part II 
I kind of prefer the way things were grouped together in 7.2 vs. 7.3. If I 
needed to check out connection information or look at query tuning flags, 
they were all right next to each other and I didn't have to scroll back and 
forth through the list.  Luckily most of the topical variables share somewhat 
common names (max_fsm_relations and max_fsm_pages) or else it would really be 
easy to overlook some settings. 

Robert Treat

On Saturday 07 June 2003 12:33 pm, Bruce Momjian wrote:
> I think people thought if you were doing SHOW ALL, you were looking for
> a specific variable, so alphabetical was best.
>
> ---------------------------------------------------------------------------
>
> Robert Treat wrote:
> > On Thu, 2003-06-05 at 11:23, Josh Berkus wrote:
> > > 4) Does anyone else have any comments on the proposed re-ordering?
> >
> > I think this was touched on before, but was there a final determination
> > of the ordering of the "show all" command? I'm hoping that will return
> > in the new order of the postgresql.conf
> >
> > Robert Treat
> > --
> > Build A Brighter Lamp :: Linux Apache {middleware} PostgreSQL
> >
> >
> > ---------------------------(end of broadcast)---------------------------
> > TIP 6: Have you searched our list archives?
> >
> > http://archives.postgresql.org


Sun, 8 Jun 2003 16:52:29 -0400
Robert Treat <xzilla@users.sourceforge.net>
Re: Proposal to Re-Order Postgresql.Conf, part II
Tom Lane wrote:
> Josh Berkus <josh@agliodbs.com> writes:
> 
>>"wal_debug" is seldom used outside of Postgresql source development or unusual 
>>system failures, and should therefore go last.
> 
> BTW, it occurs to me that wal_debug is one of the hacker-only variables
> that probably ought not be documented at all.  I cannot imagine any use
> for it for the average DBA.

Um, not documenting it is probably not a good move for us, however putting it at the end in a section marked "Developer Focused" or something similar would 
probably have the right mix of messages.  i.e. "hands off" + "not a performance tweak", etc.

:-)

Regards and best wishes,

Justin Clift


> 			regards, tom lane
> 
> ---------------------------(end of broadcast)---------------------------
> TIP 3: if posting/reading through Usenet, please send an appropriate
> subscribe-nomail command to majordomo@postgresql.org so that your
> message can get through to the mailing list cleanly


-- 
"My grandfather once told me that there are two kinds of people: those
who work and those who take the credit. He told me to try to be in the
first group; there was less competition there."
- Indira Gandhi


Mon, 09 Jun 2003 18:41:05 +0800
Justin Clift <justin@postgresql.org>
Re: Proposal to Re-Order Postgresql.Conf, part II
Tom, Justin,

> Um, not documenting it is probably not a good move for us, however putting
> it at the end in a section marked "Developer Focused" or something similar
> would probably have the right mix of messages.  i.e. "hands off" + "not a
> performance tweak", etc.

So, proposal:

1) wal_debug and the various trace_locks options will not be included in 
postgresql.conf.sample

2) they will, however, be included in the "Run Time Configuration" page, under 
a secion entitled "Source Develoment Options"

Work for everybody?

-- 
Josh Berkus
Aglio Database Solutions
San Francisco

Mon, 9 Jun 2003 09:28:45 -0700
Josh Berkus <josh@agliodbs.com>
Re: Proposal to Re-Order Postgresql.Conf, part II
Tom,

Hey, I'm looking at the postgresql.conf.sample in CVS, and can't find the 
option that's supposed to let you turn off "Inserting missing FROM clause for 
table ..."

I thought that patch was accepted 3 weeks ago?  Is this just missing from 
postgresql.conf.sample?

-- 
-Josh Berkus
 Aglio Database Solutions
 San Francisco


Mon, 9 Jun 2003 12:45:27 -0700
Josh Berkus <josh@agliodbs.com>
Re: Proposal to Re-Order Postgresql.Conf, part II
Josh Berkus <josh@agliodbs.com> writes:
> Hey, I'm looking at the postgresql.conf.sample in CVS, and can't find the 
> option that's supposed to let you turn off "Inserting missing FROM clause for
> table ..."

Bruce hasn't applied that patch yet.  I believe he's starting to catch
up the patch backlog today, though.

BTW there is also a pending patch that will add a GUC variable to
control "rendezvous" on Darwin.  I had forgotten what-all was in the
patch queue until I looked this morning.

			regards, tom lane

Mon, 09 Jun 2003 16:10:25 -0400
Tom Lane <tgl@sss.pgh.pa.us>
Re: Proposal to Re-Order Postgresql.Conf, part II 
Tom,

> Bruce hasn't applied that patch yet.  I believe he's starting to catch
> up the patch backlog today, though.
> 
> BTW there is also a pending patch that will add a GUC variable to
> control "rendezvous" on Darwin.  I had forgotten what-all was in the
> patch queue until I looked this morning.

Well, all I need right now is names for those options.  Can you give me that?

Thanks!

-- 
-Josh Berkus
 Aglio Database Solutions
 San Francisco


Mon, 9 Jun 2003 13:13:48 -0700
Josh Berkus <josh@agliodbs.com>
Re: Proposal to Re-Order Postgresql.Conf, part II
Folks,

Attached is another order outline for the Postgresql.conf parameters, updated 
for 7.4.   Please examine it, and then give your opinions on the following:

1) Should "enable_implicit_from" go in the "Version/Platform Compatibility" 
section where I have it now, or in "CLIENT CONNECTIONS-Statement Behavior", 
or somewhere else?

2) Where should "preload_libraries" go?   I'm very reluctant to start a 
"Misc." section.

3) I have re-ordered each subsection somewhat.   The fixed ordering is based 
on:
	a) My guess at the frequency with which that option will be changed, with 
more common options toward the top of the subsection;
	b) Grouping for tightly related options and for options that cascade;
	c) where (a) and (b) are unclear, alpha order.
Does this order make sense looking at the file?

3) Should we use indenting in PostgreSQL.conf.sample?   I tend to think it 
would make the file easier to read, but I'm not sure what effect it would 
have, if any, on parsing the file and whether other people would find it easy 
to read.

-- 
-Josh Berkus
 Aglio Database Solutions
 San Francisco
Mon, 9 Jun 2003 13:37:27 -0700
Josh Berkus <josh@agliodbs.com>
Re: Proposal to Re-Order Postgresql.Conf, part II
Josh Berkus wrote:
> Tom, Justin,
> 
> > Um, not documenting it is probably not a good move for us, however putting
> > it at the end in a section marked "Developer Focused" or something similar
> > would probably have the right mix of messages.  i.e. "hands off" + "not a
> > performance tweak", etc.
> 
> So, proposal:
> 
> 1) wal_debug and the various trace_locks options will not be included in 
> postgresql.conf.sample

Attached is the patch I will apply.

> 2) they will, however, be included in the "Run Time Configuration" page, under 
> a secion entitled "Source Develoment Options"

Makes sense, I guess.

-- 
  Bruce Momjian                        |  http://candle.pha.pa.us
  pgman@candle.pha.pa.us               |  (610) 359-1001
  +  If your life is a hard drive,     |  13 Roberts Road
  +  Christ can be your backup.        |  Newtown Square, Pennsylvania 19073

Index: src/backend/utils/misc/guc.c
===================================================================
RCS file: /cvsroot/pgsql-server/src/backend/utils/misc/guc.c,v
retrieving revision 1.127
diff -c -c -r1.127 guc.c
*** src/backend/utils/misc/guc.c	28 May 2003 18:19:09 -0000	1.127
--- src/backend/utils/misc/guc.c	2 Jun 2003 16:03:20 -0000
***************
*** 689,694 ****
--- 689,695 ----
  		60, 1, 600, NULL, NULL
  	},
  
+ 	/* Not for general use */
  	{
  		{"pre_auth_delay", PGC_SIGHUP}, &PreAuthDelay,
  		0, 0, 60, NULL, NULL
***************
*** 871,876 ****
--- 872,878 ----
  		"$user,public", assign_search_path, NULL
  	},
  
+ 	/* Can't be set in postgresql.conf */
  	{
  		{"server_encoding", PGC_INTERNAL, GUC_REPORT},
  		&server_encoding_string,
***************
*** 888,893 ****
--- 890,896 ----
  		"notice", assign_log_min_messages, NULL
  	},
  
+ 	/* Not for general use --- used by SET SESSION AUTHORIZATION */
  	{
  		{"session_authorization", PGC_USERSET, GUC_NO_SHOW_ALL | GUC_NO_RESET_ALL},
  		&session_authorization_string,
Index: src/backend/utils/misc/postgresql.conf.sample
===================================================================
RCS file: /cvsroot/pgsql-server/src/backend/utils/misc/postgresql.conf.sample,v
retrieving revision 1.78
diff -c -c -r1.78 postgresql.conf.sample
*** src/backend/utils/misc/postgresql.conf.sample	14 May 2003 03:26:02 -0000	1.78
--- src/backend/utils/misc/postgresql.conf.sample	2 Jun 2003 16:03:20 -0000
***************
*** 182,201 ****
  
  
  #
- #	Lock Tracing
- #
- #trace_notify = false
- 
- # requires LOCK_DEBUG
- #trace_locks = false
- #trace_userlocks = false
- #trace_lwlocks = false
- #debug_deadlocks = false
- #trace_lock_oidmin = 16384
- #trace_lock_table = 0
- 
- 
- #
  #	Misc
  #
  #dynamic_library_path = '$libdir'
--- 182,187 ----
Tue, 10 Jun 2003 00:43:16 -0400 (EDT)
Bruce Momjian <pgman@candle.pha.pa.us>
Re: Proposal to Re-Order Postgresql.Conf, part II
Josh Berkus wrote:
> Tom,
> 
> Hey, I'm looking at the postgresql.conf.sample in CVS, and can't find the 
> option that's supposed to let you turn off "Inserting missing FROM clause for 
> table ..."
> 
> I thought that patch was accepted 3 weeks ago?  Is this just missing from 
> postgresql.conf.sample?

It is in the patch queue --- I am applying tomorrow.

-- 
  Bruce Momjian                        |  http://candle.pha.pa.us
  pgman@candle.pha.pa.us               |  (610) 359-1001
  +  If your life is a hard drive,     |  13 Roberts Road
  +  Christ can be your backup.        |  Newtown Square, Pennsylvania 19073

Tue, 10 Jun 2003 00:51:49 -0400 (EDT)
Bruce Momjian <pgman@candle.pha.pa.us>
Re: Proposal to Re-Order Postgresql.Conf, part II
On Mon, 9 Jun 2003, Tom Lane wrote:

> Josh Berkus <josh@agliodbs.com> writes:
> > Hey, I'm looking at the postgresql.conf.sample in CVS, and can't find the 
> > option that's supposed to let you turn off "Inserting missing FROM clause for
> > table ..."
> 
> Bruce hasn't applied that patch yet.  I believe he's starting to catch
> up the patch backlog today, though.
> 

Are you sure about that? I seem to remember seeing the "will be applied within
24 hours" message a couple of weeks or so ago now. Is this a feature of the
recent system problems and lost patches are having to be reapplied?

As for it's name Josh, sorry, I don't have a record of my patch and the name
used in the patch differs to that which I have in my source tree.


--
Nigel Andrews


Tue, 10 Jun 2003 11:58:59 +0100 (BST)
"Nigel J. Andrews" <nandrews@investsystems.co.uk>
Re: Proposal to Re-Order Postgresql.Conf, part II
Nigel J. Andrews wrote:
> On Mon, 9 Jun 2003, Tom Lane wrote:
> 
> > Josh Berkus <josh@agliodbs.com> writes:
> > > Hey, I'm looking at the postgresql.conf.sample in CVS, and can't find the 
> > > option that's supposed to let you turn off "Inserting missing FROM clause for
> > > table ..."
> > 
> > Bruce hasn't applied that patch yet.  I believe he's starting to catch
> > up the patch backlog today, though.
> > 
> 
> Are you sure about that? I seem to remember seeing the "will be applied within
> 24 hours" message a couple of weeks or so ago now. Is this a feature of the
> recent system problems and lost patches are having to be reapplied?
> 
> As for it's name Josh, sorry, I don't have a record of my patch and the name
> used in the patch differs to that which I have in my source tree.

Yes, it is in the queue:

	http://momjian.postgresql.org/cgi-bin/pgpatches

Because of my Win32 work, I couldn't follow the 24/48 hours limit.


-- 
  Bruce Momjian                        |  http://candle.pha.pa.us
  pgman@candle.pha.pa.us               |  (610) 359-1001
  +  If your life is a hard drive,     |  13 Roberts Road
  +  Christ can be your backup.        |  Newtown Square, Pennsylvania 19073

Tue, 10 Jun 2003 11:45:01 -0400 (EDT)
Bruce Momjian <pgman@candle.pha.pa.us>
Re: Proposal to Re-Order Postgresql.Conf, part II
Justin Clift wrote:
> Tom Lane wrote:
>> Josh Berkus <josh@agliodbs.com> writes:
>> 
>>>"wal_debug" is seldom used outside of Postgresql source development or unusual 
>>>system failures, and should therefore go last.
>> 
>> BTW, it occurs to me that wal_debug is one of the hacker-only variables
>> that probably ought not be documented at all.  I cannot imagine any use
>> for it for the average DBA.
> 
> Um, not documenting it is probably not a good move for us, however putting it at the end in a section marked "Developer Focused" or something similar would 
> probably have the right mix of messages.  i.e. "hands off" + "not a performance tweak", etc.

No, not documenting it IS a good move. If there's a button people will 
press it, if there's a switch people will turn it on and if there's a 
slot people will stick in whatever they have ... believe it or not, I 
have found a Xmas cookie in the floppy drive of a consultant's notebook 
and a secretary once managed to get a 5.25'' floppy "into" an IBM PS/2 
... er ... yes, there was some kind of venting slot somewhere ... I did 
not try to explain the difference between a floppy drive and a venting 
slot to her, I converted it to the "right" format and the next time she 
came with a 5.25'' floppy directly to me :-)


Jan

-- 
#======================================================================#
# It's easier to get forgiveness for being wrong than for being right. #
# Let's break this rule - forgive me.                                  #
#================================================== JanWieck@Yahoo.com #


Tue, 10 Jun 2003 12:55:03 -0400
Jan Wieck <JanWieck@Yahoo.com>
Re: Proposal to Re-Order Postgresql.Conf, part II
Jan,

> No, not documenting it IS a good move.

I couldn't disagree more.  Undocumented options?  Who are we, Microsoft?   

>  If there's a button people will 
> press it, if there's a switch people will turn it on and if there's a 
> slot people will stick in whatever they have ... believe it or not, I 
> have found a Xmas cookie in the floppy drive of a consultant's notebook 
<snip>

These kinds of people don't read the documentation in the first place, so 
we're in no danger from them.

I can definitely see an argument that the "developer" switches should be 
documented on a different page of the docs from "Run-Time Configuration".  
But the idea of having GUCs that aren't documented at all, anywhere, is a 
very anti-Open Source idea.

-- 
-Josh Berkus
 Aglio Database Solutions
 San Francisco


Tue, 10 Jun 2003 10:28:38 -0700
Josh Berkus <josh@agliodbs.com>
Re: Proposal to Re-Order Postgresql.Conf, part II
Okay, separate documentation might work ;-)


Jan

Josh Berkus wrote:
> Jan,
> 
>> No, not documenting it IS a good move.
> 
> I couldn't disagree more.  Undocumented options?  Who are we, Microsoft?   
> 
>>  If there's a button people will 
>> press it, if there's a switch people will turn it on and if there's a 
>> slot people will stick in whatever they have ... believe it or not, I 
>> have found a Xmas cookie in the floppy drive of a consultant's notebook 
> <snip>
> 
> These kinds of people don't read the documentation in the first place, so 
> we're in no danger from them.
> 
> I can definitely see an argument that the "developer" switches should be 
> documented on a different page of the docs from "Run-Time Configuration".  
> But the idea of having GUCs that aren't documented at all, anywhere, is a 
> very anti-Open Source idea.
> 



-- 
#======================================================================#
# It's easier to get forgiveness for being wrong than for being right. #
# Let's break this rule - forgive me.                                  #
#================================================== JanWieck@Yahoo.com #


Tue, 10 Jun 2003 13:46:36 -0400
Jan Wieck <JanWieck@Yahoo.com>
Re: Proposal to Re-Order Postgresql.Conf, part II

One issue is that these settings don't even exist in most builds unless
you add compiler flags.

---------------------------------------------------------------------------

Josh Berkus wrote:
> Jan,
> 
> > No, not documenting it IS a good move.
> 
> I couldn't disagree more.  Undocumented options?  Who are we, Microsoft?   
> 
> >  If there's a button people will 
> > press it, if there's a switch people will turn it on and if there's a 
> > slot people will stick in whatever they have ... believe it or not, I 
> > have found a Xmas cookie in the floppy drive of a consultant's notebook 
> <snip>
> 
> These kinds of people don't read the documentation in the first place, so 
> we're in no danger from them.
> 
> I can definitely see an argument that the "developer" switches should be 
> documented on a different page of the docs from "Run-Time Configuration".  
> But the idea of having GUCs that aren't documented at all, anywhere, is a 
> very anti-Open Source idea.
> 
> -- 
> -Josh Berkus
>  Aglio Database Solutions
>  San Francisco
> 
> 
> ---------------------------(end of broadcast)---------------------------
> TIP 4: Don't 'kill -9' the postmaster
> 

-- 
  Bruce Momjian                        |  http://candle.pha.pa.us
  pgman@candle.pha.pa.us               |  (610) 359-1001
  +  If your life is a hard drive,     |  13 Roberts Road
  +  Christ can be your backup.        |  Newtown Square, Pennsylvania 19073

Tue, 10 Jun 2003 15:11:36 -0400 (EDT)
Bruce Momjian <pgman@candle.pha.pa.us>
Re: Proposal to Re-Order Postgresql.Conf, part II
Tom,

I'm noticing re-namining of a lot of GUCs.  As far as I can tell, the 
re-naming is based on logical reasons -- for example, "log_hostname" is more 
accurate that "hostname_lookup" -- but was a little surprised.  We'd better 
warn users who are upgrading ....

-- 
-Josh Berkus
 Aglio Database Solutions
 San Francisco


Tue, 10 Jun 2003 14:19:59 -0700
Josh Berkus <josh@agliodbs.com>
Re: Proposal to Re-Order Postgresql.Conf, part II
Tom,

Also, Autocommit seems to be gone from postgresql.conf.sample.   Was this 
intentional? 

-- 
-Josh Berkus
 Aglio Database Solutions
 San Francisco


Tue, 10 Jun 2003 14:23:23 -0700
Josh Berkus <josh@agliodbs.com>
Re: Proposal to Re-Order Postgresql.Conf, part II
Josh Berkus <josh@agliodbs.com> writes:
> Also, Autocommit seems to be gone from postgresql.conf.sample.   Was this 
> intentional? 

Yes.  It's toast ... didn't you see that flamewar a couple months ago?

			regards, tom lane

Tue, 10 Jun 2003 17:26:23 -0400
Tom Lane <tgl@sss.pgh.pa.us>
Re: Proposal to Re-Order Postgresql.Conf, part II 
Tom,

> Yes.  It's toast ... didn't you see that flamewar a couple months ago?

Nope, missed it.  There's enough traffic on this list that I ignore anything 
that I'm not working on.  

So are we eliminating the autocommit GUC entirely, or just from 
postgresql.conf?

(I never used the setting, myself ...)

-- 
-Josh Berkus
 Aglio Database Solutions
 San Francisco


Tue, 10 Jun 2003 14:27:30 -0700
Josh Berkus <josh@agliodbs.com>
Re: Proposal to Re-Order Postgresql.Conf, part II
Josh Berkus <josh@agliodbs.com> writes:
> So are we eliminating the autocommit GUC entirely, or just from 
> postgresql.conf?

Entirely --- putting it on the server side was a bad mistake, in
hindsight.  The functionality is better provided on the client side.

(The GUC var does still physically exist, but that's only so that
commands like "SET AUTOCOMMIT TO ON" will be accepted from 7.3-vintage
clients.  If you try "SET AUTOCOMMIT TO OFF" you'll get an error.
I'm unsure whether this needs to be in the documentation at all,
but it definitely doesn't need to be in postgresql.conf.sample.)

			regards, tom lane

Tue, 10 Jun 2003 17:38:13 -0400
Tom Lane <tgl@sss.pgh.pa.us>
Re: Proposal to Re-Order Postgresql.Conf, part II 
> So are we eliminating the autocommit GUC entirely, or just from 
> postgresql.conf?

It's a client side feature now.  Completely gone from the server.

-- 
Rod Taylor <rbt@rbt.ca>

PGP Key: http://www.rbt.ca/rbtpub.asc
10 Jun 2003 17:39:48 -0400
Rod Taylor <rbt@rbt.ca>
Re: Proposal to Re-Order Postgresql.Conf, part II