Here are the open items.  I think once they are resolved we can head
into beta:
	
	pg_dump multiple -t (?)
	PITR backup status file
	win32 binary version stamps
	server logging process (?)
	pg_autovacuum integration (in queue)
	pg_dump fixes (in queue)

Does anyone have any more?

-- 
  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

Mon, 2 Aug 2004 15:35:34 -0400 (EDT)
Bruce Momjian <pgman@candle.pha.pa.us>
Open items
Bruce Momjian <pgman@candle.pha.pa.us> writes:
> Here are the open items.  I think once they are resolved we can head
> into beta:
> ...
> Does anyone have any more?

contrib/dbsize doesn't even compile, and I'm still of the opinion that
oid2name is going to be pretty useless if it doesn't know about
tablespaces.

FWIW, the binary-version-stamp issue did not strike me as something
that has to be fixed before beta.

			regards, tom lane

Mon, 02 Aug 2004 17:54:21 -0400
Tom Lane <tgl@sss.pgh.pa.us>
Re: Open items 
On Mon, 2004-08-02 at 12:35, Bruce Momjian wrote:
> Does anyone have any more?

>From reading the lists it seems like most of PITR is in. However, I
can't find any docs for it so I don't know how I'd test it. I downloaded
the latest snapshot and don't immediately see anything about PITR.

Regards,
	Jeff Davis


Mon, 02 Aug 2004 15:46:02 -0700
Jeff Davis <jdavis-pgsql@empires.org>
Re: Open items
Tom Lane wrote:
> Bruce Momjian <pgman@candle.pha.pa.us> writes:
> > Here are the open items.  I think once they are resolved we can head
> > into beta:
> > ...
> > Does anyone have any more?
> 
> contrib/dbsize doesn't even compile, and I'm still of the opinion that
> oid2name is going to be pretty useless if it doesn't know about
> tablespaces.

Added to open items.
> 
> FWIW, the binary-version-stamp issue did not strike me as something
> that has to be fixed before beta.

Yea, I was unclear.  They all don't need to be completed for beta.

-- 
  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

Mon, 2 Aug 2004 21:14:31 -0400 (EDT)
Bruce Momjian <pgman@candle.pha.pa.us>
Re: Open items
Jeff Davis wrote:
> On Mon, 2004-08-02 at 12:35, Bruce Momjian wrote:
> > Does anyone have any more?
> 
> >From reading the lists it seems like most of PITR is in. However, I
> can't find any docs for it so I don't know how I'd test it. I downloaded
> the latest snapshot and don't immediately see anything about PITR.

Yep, PITR docs is an open item.

-- 
  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

Mon, 2 Aug 2004 21:15:45 -0400 (EDT)
Bruce Momjian <pgman@candle.pha.pa.us>
Re: Open items
Bruce Momjian wrote:
> Jeff Davis wrote:
> 
>>On Mon, 2004-08-02 at 12:35, Bruce Momjian wrote:
>>
>>>Does anyone have any more?
>>
>>>From reading the lists it seems like most of PITR is in. However, I
>>can't find any docs for it so I don't know how I'd test it. I downloaded
>>the latest snapshot and don't immediately see anything about PITR.
> 
> 
> Yep, PITR docs is an open item.

And is really needed because we can not play/experiment/test it without
instructions...


Regards
Gaetano Mendola



Tue, 03 Aug 2004 11:14:39 +0200
Gaetano Mendola <mendola@bigfoot.com>
Re: Open items
Bruce Momjian wrote:
> Tom Lane wrote:

>>contrib/dbsize doesn't even compile, and I'm still of the opinion that
>>oid2name is going to be pretty useless if it doesn't know about
>>tablespaces.
> 
> 
> Added to open items.

The patch I posted is now at 
http://cvs.pgadmin.org/cgi-bin/viewcvs.cgi/pgadmin-tools/support/size.c?rev=HEAD

Regards,
Andreas

Tue, 03 Aug 2004 09:26:42 +0000
Andreas Pflug <pgadmin@pse-consulting.de>
Re: Open items

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
 
 
> Here are the open items.  I think once they are resolved we can head
> into beta:
>...
> Does anyone have any more?
 
Two more:
 
It`s not a beta-blocker, but I still need to fix the postgresql.conf.sample
file to not use all those commented-out values. Unfortunately, I have not
had time to do this. If someone could take of this, it would be most
appreciated. See Tom`s notes on some issues involved:
 
http://archives.postgresql.org/pgsql-patches/2004-07/msg00178.php
 
Another reason to make sure this makes it into 8.0 is so that the new
group of users does not see the format of the file change from 8.0 to 8.1,
but can start right away with the more intuitive format.
 
Second, Jan promised at OSCON to fix up server-side prepare so it actually
works even if you do not have the exact types to pass in. I presume you
will then be able to do something like this:
 
PREPARE mystatement AS SELECT * FROM pg_class WHERE relanem = $1
 
which will make driver writers very, very happy.
 
- --
Greg Sabino Mullane greg@turnstep.com
PGP Key: 0x14964AC8 200408021700
 
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.5 (MingW32)
 
iD8DBQFBD5ePvJuQZxSWSsgRAmoGAKCwXAzTPIkvco7720ngJG+QeuYdUwCfQkAp
/Jqkq/L2UlG7C7KhmsIVFZs=
=FA/T
-----END PGP SIGNATURE-----



Tue,  3 Aug 2004 13:44:12 -0000
"Greg Sabino Mullane" <greg@turnstep.com>
Re: Open items
"Greg Sabino Mullane" <greg@turnstep.com> writes:
> Second, Jan promised at OSCON to fix up server-side prepare so it actually
> works even if you do not have the exact types to pass in. I presume you
> will then be able to do something like this:
> PREPARE mystatement AS SELECT * FROM pg_class WHERE relanem = $1
> which will make driver writers very, very happy.

Why would a driver writer care?  He can use the Prepare protocol
message, which already can do the above --- and more to the point,
there's already a way for him to *find out* what types were resolved.
There is no way for the SQL-level PREPARE command to provide info
about how types were resolved, so I'm not in favor of hacking the
SQL command this way.

			regards, tom lane

Tue, 03 Aug 2004 11:18:27 -0400
Tom Lane <tgl@sss.pgh.pa.us>
Re: Open items 
On Tuesday 03 August 2004 08:18 am, Tom Lane wrote:
> "Greg Sabino Mullane" <greg@turnstep.com> writes:
> > Second, Jan promised at OSCON to fix up server-side prepare so it
> > actually works even if you do not have the exact types to pass in. I
> > presume you will then be able to do something like this:
> > PREPARE mystatement AS SELECT * FROM pg_class WHERE relanem = $1
> > which will make driver writers very, very happy.
>
> Why would a driver writer care?  He can use the Prepare protocol
> message, which already can do the above --- and more to the point,
> there's already a way for him to *find out* what types were resolved.
> There is no way for the SQL-level PREPARE command to provide info
> about how types were resolved, so I'm not in favor of hacking the
> SQL command this way.
>

Quoth the manual (7.4):
 Presently, prepared statements for use with PQexecPrepared must be set up 
by executing an SQL PREPARE command, which is typically sent with PQexec 
(though any of libpq's query-submission functions may be used). A 
lower-level interface for preparing statements may be offered in a future 
release.

Does the new, 8.0 libpq have an interface to the prepare protocol message?

-- 
Jonathan Gardner
jgardner@jonathangardner.net

Tue, 3 Aug 2004 10:18:50 -0700
Jonathan Gardner <jgardner@jonathangardner.net>
Re: Open items
First of all "promised at OSCON to fix" is a bit exaggerated. I said I 
will look into the issue and see what can be done.

Having done something similar for the SPI manager once, so that 
parameters can have unknown type and the code calling SPI_prepare() will 
find the chosen types in the type array, so that the code calling 
SPI_execp() can do the appropriate type casting, my idea is that 
preparing a statement does the same and exec prepared actually accepts 
unknown type arguments and calls the typein function before running the 
plan. However, I still need to look at the code ...

If this is doable that way, we could log it as an open issue that needs 
to be finished for release.


Jan


On 8/3/2004 1:18 PM, Jonathan Gardner wrote:

> On Tuesday 03 August 2004 08:18 am, Tom Lane wrote:
>> "Greg Sabino Mullane" <greg@turnstep.com> writes:
>> > Second, Jan promised at OSCON to fix up server-side prepare so it
>> > actually works even if you do not have the exact types to pass in. I
>> > presume you will then be able to do something like this:
>> > PREPARE mystatement AS SELECT * FROM pg_class WHERE relanem = $1
>> > which will make driver writers very, very happy.
>>
>> Why would a driver writer care?  He can use the Prepare protocol
>> message, which already can do the above --- and more to the point,
>> there's already a way for him to *find out* what types were resolved.
>> There is no way for the SQL-level PREPARE command to provide info
>> about how types were resolved, so I'm not in favor of hacking the
>> SQL command this way.
>>
> 
> Quoth the manual (7.4):
>  Presently, prepared statements for use with PQexecPrepared must be set up 
> by executing an SQL PREPARE command, which is typically sent with PQexec 
> (though any of libpq's query-submission functions may be used). A 
> lower-level interface for preparing statements may be offered in a future 
> release.
> 
> Does the new, 8.0 libpq have an interface to the prepare protocol message?
> 


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

Tue, 03 Aug 2004 13:32:27 -0400
Jan Wieck <JanWieck@Yahoo.com>
Re: Open items
Jan Wieck <JanWieck@Yahoo.com> writes:
> Having done something similar for the SPI manager once, so that 
> parameters can have unknown type and the code calling SPI_prepare() will 
> find the chosen types in the type array, so that the code calling 
> SPI_execp() can do the appropriate type casting, my idea is that 
> preparing a statement does the same and exec prepared actually accepts 
> unknown type arguments and calls the typein function before running the 
> plan. However, I still need to look at the code ...

This is already *done*.  All we need is to devise a reasonable API for
libpq to provide access to the V3-protocol Prepare message.  I suspect
that we'd want it to bundle a Prepare and a Describe Statement
operation, so that the user would get back the list of actual argument
types in the same call that issues the prepare.  But I haven't thought
it through in detail.

> If this is doable that way, we could log it as an open issue that needs 
> to be finished for release.

[ shrug ]  Arguably it was something that should have been done for 7.4.
If someone wants to step up to the plate now, I won't stand in the way.

			regards, tom lane

Tue, 03 Aug 2004 14:46:37 -0400
Tom Lane <tgl@sss.pgh.pa.us>
Re: Open items 
On Tuesday 03 August 2004 11:46 am, Tom Lane wrote:
> Jan Wieck <JanWieck@Yahoo.com> writes:
> > Having done something similar for the SPI manager once, so that
> > parameters can have unknown type and the code calling SPI_prepare()
> > will find the chosen types in the type array, so that the code calling
> > SPI_execp() can do the appropriate type casting, my idea is that
> > preparing a statement does the same and exec prepared actually accepts
> > unknown type arguments and calls the typein function before running the
> > plan. However, I still need to look at the code ...
>
> This is already *done*.  All we need is to devise a reasonable API for
> libpq to provide access to the V3-protocol Prepare message.  I suspect
> that we'd want it to bundle a Prepare and a Describe Statement
> operation, so that the user would get back the list of actual argument
> types in the same call that issues the prepare.  But I haven't thought
> it through in detail.
>
> > If this is doable that way, we could log it as an open issue that needs
> > to be finished for release.
>
> [ shrug ]  Arguably it was something that should have been done for 7.4.
> If someone wants to step up to the plate now, I won't stand in the way.
>

As far as API, how about this: (My C is rusty...)

typedef struct PGpreparedStmt {
  char *name,
  char *stmt,
  int nParams,
  Oid *paramTypes,
} PGpreparedStmt;

PGpreparedStmt *PQprepare(PGconn *, char *name, char *stmt);

We could make the PGpreparedStmt struct opaque to the client (like PGresult 
and PGconn) and provide accessor functions.

const char *PQpreparedStmtName(const PGpreparedStmt *);
const char *PQpreparedStmtStmt(const PGpreparedStmt *);
int PQpreparedStmtNParams(const PGpreparedStmt *);
const Oid *PQpreparedStmtParamTypes(const PGpreparedStmt *);

Question: Can we handle asynchronous prepares? (I think we could follow the 
notifies method - it just magically picks it up while you consumeInput.)

int PQsendPrepare(PGconn *, char *name, char *stmt);
PGpreparedStmt *PQgetPrepare(PGconn *);

The naming could be better. I can't think of any good alternatives right 
now.

I'll look into how to actually implement this at home tonight.

-- 
Jonathan Gardner
jgardner@jonathangardner.net

Tue, 3 Aug 2004 12:12:23 -0700
Jonathan Gardner <jgardner@jonathangardner.net>
Re: Open items
> It`s not a beta-blocker, but I still need to fix the postgresql.conf.sample
> file to not use all those commented-out values. Unfortunately, I have not
> had time to do this. If someone could take of this, it would be most
> appreciated. See Tom`s notes on some issues involved:
>  
> http://archives.postgresql.org/pgsql-patches/2004-07/msg00178.php
>  
> Another reason to make sure this makes it into 8.0 is so that the new
> group of users does not see the format of the file change from 8.0 to 8.1,
> but can start right away with the more intuitive format.

This is too involved a change at this stage.  I don't expect
postgresql.conf to change any more from 7.4->8.0 than from 8.0->8.1 so I
don't see why this is more critical for this release, and it has too
many open issues.

> Second, Jan promised at OSCON to fix up server-side prepare so it actually
> works even if you do not have the exact types to pass in. I presume you
> will then be able to do something like this:
>  
> PREPARE mystatement AS SELECT * FROM pg_class WHERE relanem = $1
>  
> which will make driver writers very, very happy.

Promising does not mean it will get into CVS.

I am not in favor of doing any of these things for 8.0.  We are far past
feature freeze.  If someone wants these, they are going to have to make
a persuasive argument to the community.

-- 
  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, 3 Aug 2004 15:14:08 -0400 (EDT)
Bruce Momjian <pgman@candle.pha.pa.us>
Re: Open items
Tom Lane wrote:
> Jan Wieck <JanWieck@Yahoo.com> writes:
> > Having done something similar for the SPI manager once, so that 
> > parameters can have unknown type and the code calling SPI_prepare() will 
> > find the chosen types in the type array, so that the code calling 
> > SPI_execp() can do the appropriate type casting, my idea is that 
> > preparing a statement does the same and exec prepared actually accepts 
> > unknown type arguments and calls the typein function before running the 
> > plan. However, I still need to look at the code ...
> 
> This is already *done*.  All we need is to devise a reasonable API for
> libpq to provide access to the V3-protocol Prepare message.  I suspect
> that we'd want it to bundle a Prepare and a Describe Statement
> operation, so that the user would get back the list of actual argument
> types in the same call that issues the prepare.  But I haven't thought
> it through in detail.
> 
> > If this is doable that way, we could log it as an open issue that needs 
> > to be finished for release.
> 
> [ shrug ]  Arguably it was something that should have been done for 7.4.
> If someone wants to step up to the plate now, I won't stand in the way.

Agreed.  I will add it to the open items list.

-- 
  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, 3 Aug 2004 22:13:24 -0400 (EDT)
Bruce Momjian <pgman@candle.pha.pa.us>
Re: Open items
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

On Tuesday 03 August 2004 12:12 pm, Jonathan Gardner wrote:
> I'll look into how to actually implement this at home tonight.

Well, it's two nights later but I think I made some headway. I discovered 
the joy that is backend/tcop/postgres.c. I discovered that's were all the 
messages are dispatched.

The two messages that Tom and others have been talking about are 'P' and 
'D'.

'P' will prepare a statement. FE supplies the statement name (null is ok, 
it seems), the query, and the number of params and the param Oids. Well, 
except if you look at parse_analyze_varparams it seems that it *ignores* 
the numParams and paramTypes passed in. (I could be reading this wrong, 
so correct me.)

It seems like for 'P' we should only be sending '0' for numParams and NULL 
for paramTypes. I don't see a scenario where sending anything else is 
useful, because parse_analyse_varparams practically ignores it. (Why do 
we even have to send these?)

The response from 'P' is an empty message.

For 'D', there are two routes. One is 'S' = describe a statement, the 
other is 'P' describe a portal. I'm not clear what the difference is. 
based on stuff I've seen here, it seems that 'S' is prepared statments, 
and 'P' is for cursors. The second argument is the statement name (or the 
cursor name)

It returns two things. First comes the parameters. The code is 't', 
followed by the list length and the list of param types (Oids). Next 
comes the RowDescription, which it seems is used elsewhere. (let me guess 
- - for queries?)

So the implementation of PQprepare would look something like this.

(1) Send a 'P' message with the statmenet name and the query. Send 0 for 
nParams and Null for paramTypes.

(2) Wait for an empty message.

(3) Send a 'D' 'S' <statement name> message.

(4) Wait for a response.

(5) Take the parameters and put it into a struct. Return a reference to 
that struct.

(6) Discard the RowDescription as no one will be using them.

Comments on my rough outline and novice understanding accepted. I'll start 
coding soon unless there are objections.

- -- 
Jonathan Gardner
jgardner@jonathangardner.net
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.3 (GNU/Linux)

iD8DBQFBEdsCqp6r/MVGlwwRAk0YAKCU++UecV2oqJz77tfXGeck5xu3pQCgoQX5
kLHtQ/9XJrRjtmubohQl0Zk=
=U2Oa
-----END PGP SIGNATURE-----

Thu, 5 Aug 2004 00:00:17 -0700
"Jonathan M. Gardner" <jgardner@jonathangardner.net>
Re: Open items
"Jonathan M. Gardner" <jgardner@jonathangardner.net> writes:
> except if you look at parse_analyze_varparams it seems that it *ignores* 
> the numParams and paramTypes passed in. (I could be reading this wrong, 
> so correct me.)

You're reading it wrong.  That array is both an input and an output parameter.

			regards, tom lane

Thu, 05 Aug 2004 09:51:12 -0400
Tom Lane <tgl@sss.pgh.pa.us>
Re: Open items 
On Thursday 05 August 2004 06:51 am, Tom Lane wrote:
> "Jonathan M. Gardner" <jgardner@jonathangardner.net> writes:
> > except if you look at parse_analyze_varparams it seems that it
> > *ignores* the numParams and paramTypes passed in. (I could be reading
> > this wrong, so correct me.)
>
> You're reading it wrong.  That array is both an input and an output
> parameter.
>

I'm trying to understand the reasoning behind it, and so let me ask a few 
questions.

(1) What's the purpose of specifying the params if it is going to figure it 
out on its own?

(2) What happens when I specify a different number of params than what is in 
the query string?(3 params in query, but 4 specified, or 2 params in query, 
but 1 specified.)

(2) How do I specify something like this:
	1. Param 1 is an int.
	2. Param 2 is unknown - figure it out.
	3. Param 3 is a varchar.
Does it even make sense to specify something like that?

If these questions are answered by a discussion thread from a while back, 
I'd appreciate pointers.

Thanks for your time Tom and others, I'm enjoying this and remembering C all 
at the same time.

-- 
Jonathan Gardner
jgardner@jonathangardner.net

Thu, 5 Aug 2004 09:51:55 -0700
Jonathan Gardner <jgardner@jonathangardner.net>
Re: Open items
Jonathan Gardner <jgardner@jonathangardner.net> writes:
> (1) What's the purpose of specifying the params if it is going to figure it 
> out on its own?

It may not be able to pick an unambiguous type for an unspecified param.
Consider for instance "SELECT abs($1)".  There isn't any principled way
to pick which of the abs() functions is meant.

> (2) What happens when I specify a different number of params than what is in 
> the query string?(3 params in query, but 4 specified, or 2 params in query, 
> but 1 specified.)

The former case: the param goes unused; the latter: you get an error.

> (2) How do I specify something like this:
> 	1. Param 1 is an int.
> 	2. Param 2 is unknown - figure it out.
> 	3. Param 3 is a varchar.

23, 0, 1043 ...

			regards, tom lane

Thu, 05 Aug 2004 15:00:40 -0400
Tom Lane <tgl@sss.pgh.pa.us>
Re: Open items 

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
 
 
>> It`s not a beta-blocker, but I still need to fix the postgresql.conf.sample
>> file to not use all those commented-out values. Unfortunately, I have not
>> had time to do this. If someone could take of this, it would be most
>> appreciated. See Tom`s notes on some issues involved:
>>
>> http://archives.postgresql.org/pgsql-patches/2004-07/msg00178.php
>>
>> Another reason to make sure this makes it into 8.0 is so that the new
>> group of users does not see the format of the file change from 8.0 to 8.1,
>> but can start right away with the more intuitive format.
 
> This is too involved a change at this stage.  I don't expect
> postgresql.conf to change any more from 7.4->8.0 than from 8.0->8.1 so I
> don't see why this is more critical for this release, and it has too
> many open issues.
 
Tom's post linked above seems to indicate it might be accepted, but I
will certainly yield to Core's decision. I'm still hoping someone else
will step up to the plate and tackle this: I feel that it would be
nice not to confuse a whole new group of users with commented-out
defaults which may or may not have a relation to the actual setttings. :)
 
- --
Greg Sabino Mullane greg@turnstep.com
PGP Key: 0x14964AC8 200408052239
 
-----BEGIN PGP SIGNATURE-----
 
iD8DBQFBEu+WvJuQZxSWSsgRArFoAKD9ZwS6aRk1iONGvsJEov6UJLiAhQCgjNv3
lGz6CeH9eTzghiGJltj16IA=
=K1QP
-----END PGP SIGNATURE-----



Fri,  6 Aug 2004 02:38:48 -0000
"Greg Sabino Mullane" <greg@turnstep.com>
Re: Open items
Greg Sabino Mullane wrote:
[ There is text before PGP section. ]
> 
[ PGP not available, raw data follows ]
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
>  
>  
> >> It`s not a beta-blocker, but I still need to fix the postgresql.conf.sample
> >> file to not use all those commented-out values. Unfortunately, I have not
> >> had time to do this. If someone could take of this, it would be most
> >> appreciated. See Tom`s notes on some issues involved:
> >>
> >> http://archives.postgresql.org/pgsql-patches/2004-07/msg00178.php
> >>
> >> Another reason to make sure this makes it into 8.0 is so that the new
> >> group of users does not see the format of the file change from 8.0 to 8.1,
> >> but can start right away with the more intuitive format.
>  
> > This is too involved a change at this stage.  I don't expect
> > postgresql.conf to change any more from 7.4->8.0 than from 8.0->8.1 so I
> > don't see why this is more critical for this release, and it has too
> > many open issues.
>  
> Tom's post linked above seems to indicate it might be accepted, but I
> will certainly yield to Core's decision. I'm still hoping someone else
> will step up to the plate and tackle this: I feel that it would be
> nice not to confuse a whole new group of users with commented-out
> defaults which may or may not have a relation to the actual setttings. :)

Well, I haven't seen any of the research requested by Tom, and with beta
a few days away, I don't see it happening in time.

-- 
  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

Thu, 5 Aug 2004 23:14:05 -0400 (EDT)
Bruce Momjian <pgman@candle.pha.pa.us>
Re: Open items

Added to TODO:

	* Remove comments on postgresql.conf variables


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

Bruce Momjian wrote:
> Greg Sabino Mullane wrote:
> [ There is text before PGP section. ]
> > 
> [ PGP not available, raw data follows ]
> > -----BEGIN PGP SIGNED MESSAGE-----
> > Hash: SHA1
> >  
> >  
> > >> It`s not a beta-blocker, but I still need to fix the postgresql.conf.sample
> > >> file to not use all those commented-out values. Unfortunately, I have not
> > >> had time to do this. If someone could take of this, it would be most
> > >> appreciated. See Tom`s notes on some issues involved:
> > >>
> > >> http://archives.postgresql.org/pgsql-patches/2004-07/msg00178.php
> > >>
> > >> Another reason to make sure this makes it into 8.0 is so that the new
> > >> group of users does not see the format of the file change from 8.0 to 8.1,
> > >> but can start right away with the more intuitive format.
> >  
> > > This is too involved a change at this stage.  I don't expect
> > > postgresql.conf to change any more from 7.4->8.0 than from 8.0->8.1 so I
> > > don't see why this is more critical for this release, and it has too
> > > many open issues.
> >  
> > Tom's post linked above seems to indicate it might be accepted, but I
> > will certainly yield to Core's decision. I'm still hoping someone else
> > will step up to the plate and tackle this: I feel that it would be
> > nice not to confuse a whole new group of users with commented-out
> > defaults which may or may not have a relation to the actual setttings. :)
> 
> Well, I haven't seen any of the research requested by Tom, and with beta
> a few days away, I don't see it happening in time.
> 
> -- 
>   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
> 
> ---------------------------(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

Fri, 6 Aug 2004 11:09:07 -0400 (EDT)
Bruce Momjian <pgman@candle.pha.pa.us>
Re: Open items

Is this the proper item description?
	
	* Remove comments on postgresql.conf variables
	
	  By removing comments we prevent the confusion that commenting a line
	  returns a modified value to its default, which it does not.

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

Bruce Momjian wrote:
> 
> Added to TODO:
> 
> 	* Remove comments on postgresql.conf variables
> 
> 
> ---------------------------------------------------------------------------
> 
> Bruce Momjian wrote:
> > Greg Sabino Mullane wrote:
> > [ There is text before PGP section. ]
> > > 
> > [ PGP not available, raw data follows ]
> > > -----BEGIN PGP SIGNED MESSAGE-----
> > > Hash: SHA1
> > >  
> > >  
> > > >> It`s not a beta-blocker, but I still need to fix the postgresql.conf.sample
> > > >> file to not use all those commented-out values. Unfortunately, I have not
> > > >> had time to do this. If someone could take of this, it would be most
> > > >> appreciated. See Tom`s notes on some issues involved:
> > > >>
> > > >> http://archives.postgresql.org/pgsql-patches/2004-07/msg00178.php
> > > >>
> > > >> Another reason to make sure this makes it into 8.0 is so that the new
> > > >> group of users does not see the format of the file change from 8.0 to 8.1,
> > > >> but can start right away with the more intuitive format.
> > >  
> > > > This is too involved a change at this stage.  I don't expect
> > > > postgresql.conf to change any more from 7.4->8.0 than from 8.0->8.1 so I
> > > > don't see why this is more critical for this release, and it has too
> > > > many open issues.
> > >  
> > > Tom's post linked above seems to indicate it might be accepted, but I
> > > will certainly yield to Core's decision. I'm still hoping someone else
> > > will step up to the plate and tackle this: I feel that it would be
> > > nice not to confuse a whole new group of users with commented-out
> > > defaults which may or may not have a relation to the actual setttings. :)
> > 
> > Well, I haven't seen any of the research requested by Tom, and with beta
> > a few days away, I don't see it happening in time.
> > 
> > -- 
> >   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
> > 
> > ---------------------------(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
> 

-- 
  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

Fri, 6 Aug 2004 11:12:29 -0400 (EDT)
Bruce Momjian <pgman@candle.pha.pa.us>
Re: Open items

Hrmmm, stupid question here, but why not just change hte postgresql.conf 
to be those variables that *are* changed from the default, with a simple 
comment pointing to the documention for the rest?  the benefit of that is 
that at lesat the documentation has fuller descriptions of what the 
variables are for ...

*that* could be easily done after beta ...

On Fri, 6 Aug 2004, Bruce Momjian wrote:

>
> Is this the proper item description?
>
> 	* Remove comments on postgresql.conf variables
>
> 	  By removing comments we prevent the confusion that commenting a line
> 	  returns a modified value to its default, which it does not.
>
> ---------------------------------------------------------------------------
>
> Bruce Momjian wrote:
>>
>> Added to TODO:
>>
>> 	* Remove comments on postgresql.conf variables
>>
>>
>> ---------------------------------------------------------------------------
>>
>> Bruce Momjian wrote:
>>> Greg Sabino Mullane wrote:
>>> [ There is text before PGP section. ]
>>>>
>>> [ PGP not available, raw data follows ]
>>>> -----BEGIN PGP SIGNED MESSAGE-----
>>>> Hash: SHA1
>>>>
>>>>
>>>>>> It`s not a beta-blocker, but I still need to fix the postgresql.conf.sample
>>>>>> file to not use all those commented-out values. Unfortunately, I have not
>>>>>> had time to do this. If someone could take of this, it would be most
>>>>>> appreciated. See Tom`s notes on some issues involved:
>>>>>>
>>>>>> http://archives.postgresql.org/pgsql-patches/2004-07/msg00178.php
>>>>>>
>>>>>> Another reason to make sure this makes it into 8.0 is so that the new
>>>>>> group of users does not see the format of the file change from 8.0 to 8.1,
>>>>>> but can start right away with the more intuitive format.
>>>>
>>>>> This is too involved a change at this stage.  I don't expect
>>>>> postgresql.conf to change any more from 7.4->8.0 than from 8.0->8.1 so I
>>>>> don't see why this is more critical for this release, and it has too
>>>>> many open issues.
>>>>
>>>> Tom's post linked above seems to indicate it might be accepted, but I
>>>> will certainly yield to Core's decision. I'm still hoping someone else
>>>> will step up to the plate and tackle this: I feel that it would be
>>>> nice not to confuse a whole new group of users with commented-out
>>>> defaults which may or may not have a relation to the actual setttings. :)
>>>
>>> Well, I haven't seen any of the research requested by Tom, and with beta
>>> a few days away, I don't see it happening in time.
>>>
>>> --
>>>   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
>>>
>>> ---------------------------(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
>>
>
> --
>  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
>
> ---------------------------(end of broadcast)---------------------------
> TIP 4: Don't 'kill -9' the postmaster
>

----
Marc G. Fournier           Hub.Org Networking Services (http://www.hub.org)
Email: scrappy@hub.org           Yahoo!: yscrappy              ICQ: 7615664

Fri, 6 Aug 2004 12:29:00 -0300 (ADT)
"Marc G. Fournier" <scrappy@postgresql.org>
Re: Open items
Marc G. Fournier wrote:
> 
> Hrmmm, stupid question here, but why not just change hte postgresql.conf 
> to be those variables that *are* changed from the default, with a simple 
> comment pointing to the documention for the rest?  the benefit of that is 
> that at lesat the documentation has fuller descriptions of what the 
> variables are for ...
> 
> *that* could be easily done after beta ...

Not sure why removing the comments is seen as good myself, but I think
the idea was that if you comment out something and change the default,
you assume that commenting it out returns it to the default, though it
does not.

I am unclear on your suggestion above.

-- 
  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

Fri, 6 Aug 2004 11:33:49 -0400 (EDT)
Bruce Momjian <pgman@candle.pha.pa.us>
Re: Open items
On Fri, 6 Aug 2004, Bruce Momjian wrote:

> Marc G. Fournier wrote:
>>
>> Hrmmm, stupid question here, but why not just change hte postgresql.conf
>> to be those variables that *are* changed from the default, with a simple
>> comment pointing to the documention for the rest?  the benefit of that is
>> that at lesat the documentation has fuller descriptions of what the
>> variables are for ...
>>
>> *that* could be easily done after beta ...
>
> Not sure why removing the comments is seen as good myself, but I think
> the idea was that if you comment out something and change the default,
> you assume that commenting it out returns it to the default, though it
> does not.

'k, now you've totally confused me ... if you comment something out, and 
it doesn't return to the default, where does it go to?

my understanding was that the 'beef' was that the defaults that are 
displayed on each of the variables in postgresql.conf file don't 
necessarily match the defaults compiled into the backend ... which, I 
*think* is what you meant in the above? :)

Right now, if you install postgresql, there are various variables 
added/set in the postgresql.conf file (notably the stuff that Tom did with 
the shared memory buffer) ... with the rest being "what could be the 
default, but may not be" for the commented out variables ... my suggestion 
is to remove the commented out variables altogether, and change the file 
to something like:

#
# for a complete list of GUC variables, see ...
#
<put 'live/set' variables here>


----
Marc G. Fournier           Hub.Org Networking Services (http://www.hub.org)
Email: scrappy@hub.org           Yahoo!: yscrappy              ICQ: 7615664

Fri, 6 Aug 2004 12:59:14 -0300 (ADT)
"Marc G. Fournier" <scrappy@postgresql.org>
Re: Open items

If you change shared_buffers to 2000, remove the comment and reload, the
variable is now 2000.  If you comment out the variable and reload again,
it is still 2000, not the default.

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

Marc G. Fournier wrote:
> On Fri, 6 Aug 2004, Bruce Momjian wrote:
> 
> > Marc G. Fournier wrote:
> >>
> >> Hrmmm, stupid question here, but why not just change hte postgresql.conf
> >> to be those variables that *are* changed from the default, with a simple
> >> comment pointing to the documention for the rest?  the benefit of that is
> >> that at lesat the documentation has fuller descriptions of what the
> >> variables are for ...
> >>
> >> *that* could be easily done after beta ...
> >
> > Not sure why removing the comments is seen as good myself, but I think
> > the idea was that if you comment out something and change the default,
> > you assume that commenting it out returns it to the default, though it
> > does not.
> 
> 'k, now you've totally confused me ... if you comment something out, and 
> it doesn't return to the default, where does it go to?
> 
> my understanding was that the 'beef' was that the defaults that are 
> displayed on each of the variables in postgresql.conf file don't 
> necessarily match the defaults compiled into the backend ... which, I 
> *think* is what you meant in the above? :)
> 
> Right now, if you install postgresql, there are various variables 
> added/set in the postgresql.conf file (notably the stuff that Tom did with 
> the shared memory buffer) ... with the rest being "what could be the 
> default, but may not be" for the commented out variables ... my suggestion 
> is to remove the commented out variables altogether, and change the file 
> to something like:
> 
> #
> # for a complete list of GUC variables, see ...
> #
> <put 'live/set' variables here>
> 
> 
> ----
> Marc G. Fournier           Hub.Org Networking Services (http://www.hub.org)
> Email: scrappy@hub.org           Yahoo!: yscrappy              ICQ: 7615664
> 

-- 
  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

Fri, 6 Aug 2004 12:13:05 -0400 (EDT)
Bruce Momjian <pgman@candle.pha.pa.us>
Re: Open items
Bruce Momjian <pgman@candle.pha.pa.us> writes:
> Is this the proper item description?
	
> 	* Remove comments on postgresql.conf variables

It could easily be taken to mean removing this:

#authentication_timeout = 60    # 1-600, in seconds
                                ^^^^^^^^^^^^^^^^^^^

rather than the leading #.  I'd suggest

	* Un-comment all variables in postgresql.conf

	  By not showing commented-out variables, we will discourage
	  people from thinking that re-commenting a variable returns it
	  to its default.

			regards, tom lane

Fri, 06 Aug 2004 12:29:27 -0400
Tom Lane <tgl@sss.pgh.pa.us>
Re: Open items 
On Fri, 6 Aug 2004, Bruce Momjian wrote:

>
> If you change shared_buffers to 2000, remove the comment and reload, the
> variable is now 2000.  If you comment out the variable and reload again,
> it is still 2000, not the default.

Oh, weird ... and that isn't considered a bug?  Definitely wouldn't be the 
behaviour I would have expected of any other server/daemon process ... now 
I can see where the confusion is arising :(

> Marc G. Fournier wrote:
>> On Fri, 6 Aug 2004, Bruce Momjian wrote:
>>
>>> Marc G. Fournier wrote:
>>>>
>>>> Hrmmm, stupid question here, but why not just change hte postgresql.conf
>>>> to be those variables that *are* changed from the default, with a simple
>>>> comment pointing to the documention for the rest?  the benefit of that is
>>>> that at lesat the documentation has fuller descriptions of what the
>>>> variables are for ...
>>>>
>>>> *that* could be easily done after beta ...
>>>
>>> Not sure why removing the comments is seen as good myself, but I think
>>> the idea was that if you comment out something and change the default,
>>> you assume that commenting it out returns it to the default, though it
>>> does not.
>>
>> 'k, now you've totally confused me ... if you comment something out, and
>> it doesn't return to the default, where does it go to?
>>
>> my understanding was that the 'beef' was that the defaults that are
>> displayed on each of the variables in postgresql.conf file don't
>> necessarily match the defaults compiled into the backend ... which, I
>> *think* is what you meant in the above? :)
>>
>> Right now, if you install postgresql, there are various variables
>> added/set in the postgresql.conf file (notably the stuff that Tom did with
>> the shared memory buffer) ... with the rest being "what could be the
>> default, but may not be" for the commented out variables ... my suggestion
>> is to remove the commented out variables altogether, and change the file
>> to something like:
>>
>> #
>> # for a complete list of GUC variables, see ...
>> #
>> <put 'live/set' variables here>
>>
>>
>> ----
>> Marc G. Fournier           Hub.Org Networking Services (http://www.hub.org)
>> Email: scrappy@hub.org           Yahoo!: yscrappy              ICQ: 7615664
>>
>
> --
>  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
>

----
Marc G. Fournier           Hub.Org Networking Services (http://www.hub.org)
Email: scrappy@hub.org           Yahoo!: yscrappy              ICQ: 7615664

Fri, 6 Aug 2004 13:31:21 -0300 (ADT)
"Marc G. Fournier" <scrappy@postgresql.org>
Re: Open items
On Fri, 6 Aug 2004, Tom Lane wrote:

> Bruce Momjian <pgman@candle.pha.pa.us> writes:
>> Is this the proper item description?
>
>> 	* Remove comments on postgresql.conf variables
>
> It could easily be taken to mean removing this:
>
> #authentication_timeout = 60    # 1-600, in seconds
>                                ^^^^^^^^^^^^^^^^^^^
>
> rather than the leading #.  I'd suggest
>
> 	* Un-comment all variables in postgresql.conf
>
> 	  By not showing commented-out variables, we will discourage
> 	  people from thinking that re-commenting a variable returns it
> 	  to its default.

That works ... then it implies that there are just no defaults, which, 
IMHO, would definitely cause less confusion :)

----
Marc G. Fournier           Hub.Org Networking Services (http://www.hub.org)
Email: scrappy@hub.org           Yahoo!: yscrappy              ICQ: 7615664

Fri, 6 Aug 2004 13:36:23 -0300 (ADT)
"Marc G. Fournier" <scrappy@postgresql.org>
Re: Open items 

Done.

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

Tom Lane wrote:
> Bruce Momjian <pgman@candle.pha.pa.us> writes:
> > Is this the proper item description?
> 	
> > 	* Remove comments on postgresql.conf variables
> 
> It could easily be taken to mean removing this:
> 
> #authentication_timeout = 60    # 1-600, in seconds
>                                 ^^^^^^^^^^^^^^^^^^^
> 
> rather than the leading #.  I'd suggest
> 
> 	* Un-comment all variables in postgresql.conf
> 
> 	  By not showing commented-out variables, we will discourage
> 	  people from thinking that re-commenting a variable returns it
> 	  to its default.
> 
> 			regards, tom lane
> 

-- 
  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

Fri, 6 Aug 2004 13:52:46 -0400 (EDT)
Bruce Momjian <pgman@candle.pha.pa.us>
Re: Open items