Sorry, i'm resending because i forgot the subject

On 7/17/06, Jaime Casanova <systemguards@gmail.com> wrote:
> Hi,
>
> when searching the TODO list (http://www.postgresql.org/docs/faqs.TODO.html).
>
> i found this on the Monitoring section:
>
> o Allow protocol-level BIND parameter values to be logged
> http://archives.postgresql.org/pgsql...2/msg00165.php
>
> But i don't understand why that thread is related to the TODO item,
> i'm missing something?
>
> --
> Atentamente,
> Jaime Casanova
>
> "Programming today is a race between software engineers striving to
> build bigger and better idiot-proof programs and the universe trying
> to produce bigger and better idiots.
> So far, the universe is winning."
> Richard Cook
>


--
Atentamente,
Jaime Casanova

"Programming today is a race between software engineers striving to
build bigger and better idiot-proof programs and the universe trying
to produce bigger and better idiots.
So far, the universe is winning."
Richard Cook

---------------------------(end of broadcast)---------------------------
TIP 3: Have you checked our extensive FAQ?

http://www.postgresql.org/docs/faq

On Mon, Jul 17, 2006 at 12:25:09AM -0500, Jaime Casanova wrote:
> when searching the TODO list
> (http://www.postgresql.org/docs/faqs.TODO.html).
>
> i found this on the Monitoring section:
>
> o Allow protocol-level BIND parameter values to be logged
> http://archives.postgresql.org/pgsql...2/msg00165.php
>
> But i don't understand why that thread is related to the TODO item,
> i'm missing something?

Possibly the message renumbering that Tom griped about:

http://archives.postgresql.org/pgsql...7/msg00061.php

--
Michael Fuhr

---------------------------(end of broadcast)---------------------------
TIP 5: don't forget to increase your free space map settings

Michael Fuhr <mike@fuhr.org> writes:
> On Mon, Jul 17, 2006 at 12:25:09AM -0500, Jaime Casanova wrote:
>> i found this on the Monitoring section:
>> o Allow protocol-level BIND parameter values to be logged
>> http://archives.postgresql.org/pgsql...2/msg00165.php
>>
>> But i don't understand why that thread is related to the TODO item,
>> i'm missing something?

> Possibly the message renumbering that Tom griped about:
> http://archives.postgresql.org/pgsql...7/msg00061.php

Yeah. I think the TODO item is intended to point to what is now
http://archives.postgresql.org/pgsql...2/msg00163.php
or one of the earlier messages in that thread.

Perhaps when Bruce realizes he needs to recheck every link in the
TODO files, he'll get on the warpath with me ;-)

regards, tom lane

---------------------------(end of broadcast)---------------------------
TIP 3: Have you checked our extensive FAQ?

http://www.postgresql.org/docs/faq

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1


>> http://archives.postgresql.org/pgsql...7/msg00061.php
>
> Yeah. I think the TODO item is intended to point to what is now
> http://archives.postgresql.org/pgsql...2/msg00163.php
> or one of the earlier messages in that thread.

This is a very ugly problem. Note that there are also URLs that cannot
be changed, such as older messages that point to archive posts, and
many places on the web outside of our control.

Why can't we just write a script that creates new numbers as needed,
such as msg00163.1.php and msg00163.2.php? As far as I can tell, there
is nothing magical about the naming schema itself that would cause
such URLs to break anything.

- --
Greg Sabino Mullane greg@turnstep.com
PGP Key: 0x14964AC8 200607170743
http://biglumber.com/x/web?pk=2529DF...9B906714964AC8
-----BEGIN PGP SIGNATURE-----

iD8DBQFEu3iovJuQZxSWSsgRAqafAKD51/vpiZnDkHyCQ2TrPkPEXPUQbwCfVRux
5Rw14QzglcYed2A54IGtKrc=
=hz49
-----END PGP SIGNATURE-----



---------------------------(end of broadcast)---------------------------
TIP 5: don't forget to increase your free space map settings

Greg Sabino Mullane wrote:
[ There is text before PGP section. ]
>
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
>
>
> >> http://archives.postgresql.org/pgsql...7/msg00061.php
> >
> > Yeah. I think the TODO item is intended to point to what is now
> > http://archives.postgresql.org/pgsql...2/msg00163.php
> > or one of the earlier messages in that thread.
>
> This is a very ugly problem. Note that there are also URLs that cannot
> be changed, such as older messages that point to archive posts, and
> many places on the web outside of our control.
>
> Why can't we just write a script that creates new numbers as needed,
> such as msg00163.1.php and msg00163.2.php? As far as I can tell, there
> is nothing magical about the naming schema itself that would cause
> such URLs to break anything.

Agreed. It is nice to have the emails numbered in arrival order, but
changes to old URLs are worse.

--
Bruce Momjian bruce@momjian.us
EnterpriseDB http://www.enterprisedb.com

+ If your life is a hard drive, Christ can be your backup. +

---------------------------(end of broadcast)---------------------------
TIP 1: 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

Tom Lane wrote:
> Michael Fuhr <mike@fuhr.org> writes:
> > On Mon, Jul 17, 2006 at 12:25:09AM -0500, Jaime Casanova wrote:
> >> i found this on the Monitoring section:
> >> o Allow protocol-level BIND parameter values to be logged
> >> http://archives.postgresql.org/pgsql...2/msg00165.php
> >>
> >> But i don't understand why that thread is related to the TODO item,
> >> i'm missing something?
>
> > Possibly the message renumbering that Tom griped about:
> > http://archives.postgresql.org/pgsql...7/msg00061.php
>
> Yeah. I think the TODO item is intended to point to what is now
> http://archives.postgresql.org/pgsql...2/msg00163.php
> or one of the earlier messages in that thread.
>
> Perhaps when Bruce realizes he needs to recheck every link in the
> TODO files, he'll get on the warpath with me ;-)

(Sorry, just catching up on this issue.)

Yes, I can fix the TODO item URLs, but many email messages reference
URLs themselves:

http://archives.postgresql.org/pgsql...6/msg00096.php

The URL in the email actually works, but I am sure others do not.
Because we don't have control over the email contents (think Google), I
don't think we can renumber old email items without a continual stream
of complaints from users.

--
Bruce Momjian bruce@momjian.us
EnterpriseDB http://www.enterprisedb.com

+ If your life is a hard drive, Christ can be your backup. +

---------------------------(end of broadcast)---------------------------
TIP 1: 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

> Tom Lane wrote:
> > Michael Fuhr <mike@fuhr.org> writes:
> > > On Mon, Jul 17, 2006 at 12:25:09AM -0500, Jaime Casanova wrote:
> > >> i found this on the Monitoring section:
> > >> o Allow protocol-level BIND parameter values to be logged
> > >> http://archives.postgresql.org/pgsql...2/msg00165.php
> > >>
> > >> But i don't understand why that thread is related to the TODO item,
> > >> i'm missing something?
> >
> > > Possibly the message renumbering that Tom griped about:
> > > http://archives.postgresql.org/pgsql...7/msg00061.php
> >
> > Yeah. I think the TODO item is intended to point to what is now
> > http://archives.postgresql.org/pgsql...2/msg00163.php
> > or one of the earlier messages in that thread.
> >
> > Perhaps when Bruce realizes he needs to recheck every link in the
> > TODO files, he'll get on the warpath with me ;-)
>
> (Sorry, just catching up on this issue.)
>
> Yes, I can fix the TODO item URLs, but many email messages reference
> URLs themselves:
>
> http://archives.postgresql.org/pgsql...6/msg00096.php
>
> The URL in the email actually works, but I am sure others do not.
> Because we don't have control over the email contents (think Google), I
> don't think we can renumber old email items without a continual stream
> of complaints from users.

I always wonder why we don't add a unique id to each email message
itself. I mean let the mail list program to add sequencial number to
each email's subject. For example, emails pgsql-jp ML (PostgreSQL general
discussion in Japanese managed by JPUG) have subject headers like
this:

[pgsql-jp: 34814] pgpool 2.5 released

By using this method our TODO list can referer emais "logical" id
(34814 in this case) which is independent on archive URL.
Archive URL is something like a "phisical" id and maybe changed
accidentaly and is not convenitent for this kind of usage IMO.
--
Tatsuo Ishii
SRA OSS, Inc. Japan

---------------------------(end of broadcast)---------------------------
TIP 4: Have you searched our list archives?

http://archives.postgresql.org

Tatsuo Ishii <ishii@sraoss.co.jp> writes:
>> Because we don't have control over the email contents (think Google), I
>> don't think we can renumber old email items without a continual stream
>> of complaints from users.

> I always wonder why we don't add a unique id to each email message
> itself.

But that doesn't do anything to fix the immediate problem ...

regards, tom lane

---------------------------(end of broadcast)---------------------------
TIP 6: explain analyze is your friend

On Tue, 18 Jul 2006, Bruce Momjian wrote:

> Greg Sabino Mullane wrote:
> [ There is text before PGP section. ]
>>
>> -----BEGIN PGP SIGNED MESSAGE-----
>> Hash: SHA1
>>
>>
>>>> http://archives.postgresql.org/pgsql...7/msg00061.php
>>>
>>> Yeah. I think the TODO item is intended to point to what is now
>>> http://archives.postgresql.org/pgsql...2/msg00163.php
>>> or one of the earlier messages in that thread.
>>
>> This is a very ugly problem. Note that there are also URLs that cannot
>> be changed, such as older messages that point to archive posts, and
>> many places on the web outside of our control.
>>
>> Why can't we just write a script that creates new numbers as needed,
>> such as msg00163.1.php and msg00163.2.php? As far as I can tell, there
>> is nothing magical about the naming schema itself that would cause
>> such URLs to break anything.
>
> Agreed. It is nice to have the emails numbered in arrival order, but
> changes to old URLs are worse.

'k, so is the concensus here that I regenerate everything with the 'broken
msg seperator', and then revert to the unbroken one for new stuff? its no
sweat, I just fear this is going to re-crop up sometime in the future if
we ever have to regenerate from the mbox files, as well have some in
'broken format' and some in the 'unbroken', but renumbering *then* will
still affect everything ...

Basically, we're just differing the headaches to a later date when we have
no choice

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

---------------------------(end of broadcast)---------------------------
TIP 9: In versions below 8.0, the planner will ignore your desire to
choose an index scan if your joining column's datatypes do not
match

Marc G. Fournier wrote:

> 'k, so is the concensus here that I regenerate everything with the 'broken
> msg seperator', and then revert to the unbroken one for new stuff? its no
> sweat, I just fear this is going to re-crop up sometime in the future if
> we ever have to regenerate from the mbox files, as well have some in
> 'broken format' and some in the 'unbroken', but renumbering *then* will
> still affect everything ...

One idea is to keep the old archives using the broken separator, and
regenerate the good archives in some other directory, or with a
different prefix (say, instead of msg0234.php have it be named
mesg0234.php or msg0234.1.php, etc). That way the old URLs would
continue to work, and there wouldn't be a problem if the archives need
to be regenerated in the future.

OTOH it would be good to have a collection of messages by Message-Id
which could be used as a permalink. For example

http://archives.postgresql.org/by-id...nymede.hub.org

or something like that.

--
Alvaro Herrera http://www.CommandPrompt.com/
PostgreSQL Replication, Consulting, Custom Development, 24x7 support

---------------------------(end of broadcast)---------------------------
TIP 5: don't forget to increase your free space map settings