Thread: TODO: Rename some /contrib modules from pg* to pg_*
Hello, I read this as: 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 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 solutionssince 1997 http://www.commandprompt.com/
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 solutionssince 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 solutionssince 1997 http://www.commandprompt.com/
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
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
"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. +