TODO: Rename some /contrib modules from pg* to pg_*

Joshua D. Drake wrote:

Hello,

I read this as:

1. Fix makefiles so that contrib modules such as pgcrypto are not pg_crypto

err "are now"

2. Move directories to reflect above

3. Fix source and makefiles within sub project directories to create
binaries and libs with correct output.. thus libpgcrypto.so.0.0 would
become libpg_crypto.so.0.0

Is this correct? If so I personally would like to claim this TODO.

Joshua D. Drake

--

=== The PostgreSQL Company: Command Prompt, Inc. ===
Sales/Support: +1.503.667.4564 || 24x7/Emergency: +1.800.492.2240
Providing the most comprehensive PostgreSQL solutions since 1997
http://www.commandprompt.com/

"Joshua D. Drake" <jd@commandprompt.com> writes:

1. Fix makefiles so that contrib modules such as pgcrypto are not pg_crypto
2. Move directories to reflect above
3. Fix source and makefiles within sub project directories to create
binaries and libs with correct output.. thus libpgcrypto.so.0.0 would
become libpg_crypto.so.0.0

That will lose the CVS history of the modules, which is not worth the
small benefit gained from more consistent-looking names. Renaming
existing shared libraries is also a very bad idea, because it will
break existing dump scripts.

I don't know when that TODO item got put in, but it's a stupid idea.

regards, tom lane

Tom Lane wrote:

"Joshua D. Drake" <jd@commandprompt.com> writes:

1. Fix makefiles so that contrib modules such as pgcrypto are not pg_crypto
2. Move directories to reflect above
3. Fix source and makefiles within sub project directories to create
binaries and libs with correct output.. thus libpgcrypto.so.0.0 would
become libpg_crypto.so.0.0

That will lose the CVS history of the modules, which is not worth the
small benefit gained from more consistent-looking names. Renaming
existing shared libraries is also a very bad idea, because it will
break existing dump scripts.

I don't know when that TODO item got put in, but it's a stupid idea.

O.k. just trying to help :)

Joshua D. Drake

regards, tom lane

--

=== The PostgreSQL Company: Command Prompt, Inc. ===
Sales/Support: +1.503.667.4564 || 24x7/Emergency: +1.800.492.2240
Providing the most comprehensive PostgreSQL solutions since 1997
http://www.commandprompt.com/

Marc G. Fournier said:

On Thu, 8 Jun 2006, Tom Lane wrote:

"Joshua D. Drake" <jd@commandprompt.com> writes:

1. Fix makefiles so that contrib modules such as pgcrypto are not
pg_crypto 2. Move directories to reflect above
3. Fix source and makefiles within sub project directories to create
binaries and libs with correct output.. thus libpgcrypto.so.0.0 would
become libpg_crypto.so.0.0

That will lose the CVS history of the modules

Umm, if co-ordinated with me, I can make the name changes at the file
system level, so that history isn't lost ..

Renaming directories is nasty in CVS no matter which way you look at it - it
is one of the known bad limitations. You might preserve the history but you
could also break every existing repo copy. See
http://ximbiot.com/cvs/manual/cvs-1.11.15/cvs_7.html#SEC74

Unless there is a *very* good reason this should be avoided.

cheers

andrew

On Thu, 8 Jun 2006, Tom Lane wrote:

"Joshua D. Drake" <jd@commandprompt.com> writes:

1. Fix makefiles so that contrib modules such as pgcrypto are not pg_crypto
2. Move directories to reflect above
3. Fix source and makefiles within sub project directories to create
binaries and libs with correct output.. thus libpgcrypto.so.0.0 would
become libpg_crypto.so.0.0

That will lose the CVS history of the modules

Umm, if co-ordinated with me, I can make the name changes at the file
system level, so that history isn't lost ..

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

"Andrew Dunstan" <andrew@dunslane.net> writes:

Renaming directories is nasty in CVS no matter which way you look at it - it
is one of the known bad limitations. You might preserve the history but you
could also break every existing repo copy. See
http://ximbiot.com/cvs/manual/cvs-1.11.15/cvs_7.html#SEC74

Unless there is a *very* good reason this should be avoided.

I think the we-shouldn't-rename-the-shlibs argument is sufficient to
kill the idea, quite aside from CVS limitations.

regards, tom lane

Tom Lane wrote:

"Andrew Dunstan" <andrew@dunslane.net> writes:

Renaming directories is nasty in CVS no matter which way you look at it - it
is one of the known bad limitations. You might preserve the history but you
could also break every existing repo copy. See
http://ximbiot.com/cvs/manual/cvs-1.11.15/cvs_7.html#SEC74

Unless there is a *very* good reason this should be avoided.

I think the we-shouldn't-rename-the-shlibs argument is sufficient to
kill the idea, quite aside from CVS limitations.

TODO removed.

--
Bruce Momjian http://candle.pha.pa.us
EnterpriseDB http://www.enterprisedb.com

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