Re: Open items

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(at)candle(dot)pha(dot)pa(dot)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 <pgman(at)candle(dot)pha(dot)pa(dot)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

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

Tom Lane wrote:
> Bruce Momjian <pgman(at)candle(dot)pha(dot)pa(dot)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(at)candle(dot)pha(dot)pa(dot)us | (610) 359-1001
+ If your life is a hard drive, | 13 Roberts Road
+ Christ can be your backup. | Newtown Square, Pennsylvania 19073

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(at)candle(dot)pha(dot)pa(dot)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 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

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

-----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(at)turnstep(dot)com
PGP Key: 0x14964AC8 200408021700

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.5 (MingW32)

iD8DBQFBD5ePvJuQZxSWSsgRAmoGAKCwXAzTPIkvco7720ngJG+QeuYdUwCfQkAp
/Jqkq/L2UlG7C7KhmsIVFZs=
=FA/T
-----END PGP SIGNATURE-----

"Greg Sabino Mullane" <greg(at)turnstep(dot)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

On Tuesday 03 August 2004 08:18 am, Tom Lane wrote:
> "Greg Sabino Mullane" <greg(at)turnstep(dot)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(at)jonathangardner(dot)net

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(at)turnstep(dot)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(at)Yahoo(dot)com #

Jan Wieck <JanWieck(at)Yahoo(dot)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

On Tuesday 03 August 2004 11:46 am, Tom Lane wrote:
> Jan Wieck <JanWieck(at)Yahoo(dot)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(at)jonathangardner(dot)net

> 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(at)candle(dot)pha(dot)pa(dot)us | (610) 359-1001
+ If your life is a hard drive, | 13 Roberts Road
+ Christ can be your backup. | Newtown Square, Pennsylvania 19073

Tom Lane wrote:
> Jan Wieck <JanWieck(at)Yahoo(dot)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(at)candle(dot)pha(dot)pa(dot)us | (610) 359-1001
+ If your life is a hard drive, | 13 Roberts Road
+ Christ can be your backup. | Newtown Square, Pennsylvania 19073

-----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(at)jonathangardner(dot)net
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.3 (GNU/Linux)

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

"Jonathan M. Gardner" <jgardner(at)jonathangardner(dot)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

On Thursday 05 August 2004 06:51 am, Tom Lane wrote:
> "Jonathan M. Gardner" <jgardner(at)jonathangardner(dot)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(at)jonathangardner(dot)net

Jonathan Gardner <jgardner(at)jonathangardner(dot)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

-----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(at)turnstep(dot)com
PGP Key: 0x14964AC8 200408052239

-----BEGIN PGP SIGNATURE-----

iD8DBQFBEu+WvJuQZxSWSsgRArFoAKD9ZwS6aRk1iONGvsJEov6UJLiAhQCgjNv3
lGz6CeH9eTzghiGJltj16IA=
=K1QP
-----END PGP SIGNATURE-----

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(at)candle(dot)pha(dot)pa(dot)us | (610) 359-1001
+ If your life is a hard drive, | 13 Roberts Road
+ Christ can be your backup. | Newtown Square, Pennsylvania 19073

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(at)candle(dot)pha(dot)pa(dot)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(at)candle(dot)pha(dot)pa(dot)us | (610) 359-1001
+ If your life is a hard drive, | 13 Roberts Road
+ Christ can be your backup. | Newtown Square, Pennsylvania 19073

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(at)candle(dot)pha(dot)pa(dot)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(at)candle(dot)pha(dot)pa(dot)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(at)candle(dot)pha(dot)pa(dot)us | (610) 359-1001
+ If your life is a hard drive, | 13 Roberts Road
+ Christ can be your backup. | Newtown Square, Pennsylvania 19073

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(at)candle(dot)pha(dot)pa(dot)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(at)candle(dot)pha(dot)pa(dot)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(at)candle(dot)pha(dot)pa(dot)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(at)hub(dot)org Yahoo!: yscrappy ICQ: 7615664

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(at)candle(dot)pha(dot)pa(dot)us | (610) 359-1001
+ If your life is a hard drive, | 13 Roberts Road
+ Christ can be your backup. | Newtown Square, Pennsylvania 19073

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(at)hub(dot)org Yahoo!: yscrappy ICQ: 7615664

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(at)hub(dot)org Yahoo!: yscrappy ICQ: 7615664
>

--
Bruce Momjian | http://candle.pha.pa.us
pgman(at)candle(dot)pha(dot)pa(dot)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 <pgman(at)candle(dot)pha(dot)pa(dot)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

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(at)hub(dot)org Yahoo!: yscrappy ICQ: 7615664
>>
>
> --
> Bruce Momjian | http://candle.pha.pa.us
> pgman(at)candle(dot)pha(dot)pa(dot)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(at)hub(dot)org Yahoo!: yscrappy ICQ: 7615664

On Fri, 6 Aug 2004, Tom Lane wrote:

> Bruce Momjian <pgman(at)candle(dot)pha(dot)pa(dot)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(at)hub(dot)org Yahoo!: yscrappy ICQ: 7615664

Done.

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

Tom Lane wrote:
> Bruce Momjian <pgman(at)candle(dot)pha(dot)pa(dot)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(at)candle(dot)pha(dot)pa(dot)us | (610) 359-1001
+ If your life is a hard drive, | 13 Roberts Road
+ Christ can be your backup. | Newtown Square, Pennsylvania 19073