Thread: Next release is 7.0(?)
Because the next release is going to probably be 7.0, if people have backward compatability library code that they have been dying to remove, this is the time for it. I don't recommend removing backward compatability with 6.4 or 6.5 releases, but if you have some code that is hanging around just to be compatible with 6.1 or earlier, I think it can be removed now. -- Bruce Momjian | http://www.op.net/~candle maillist@candle.pha.pa.us | (610) 853-3000+ If your life is a hard drive, | 830 Blythe Avenue + Christ can be your backup. | Drexel Hill, Pennsylvania19026
On Sat, 9 Oct 1999, Bruce Momjian wrote: > Because the next release is going to probably be 7.0, if people have > backward compatability library code that they have been dying to remove, > this is the time for it. > > I don't recommend removing backward compatability with 6.4 or 6.5 > releases, but if you have some code that is hanging around just to be > compatible with 6.1 or earlier, I think it can be removed now. > > Then perhaps we can also overhaul the installation. I installed about 5 times this past week and have it down to 4 or 5 steps (not including regression testing). Vince. -- ========================================================================== Vince Vielhaber -- KA8CSH email: vev@michvhf.com flame-mail: /dev/null # include <std/disclaimers.h> Have you seenhttp://www.pop4.net? Online Campground Directory http://www.camping-usa.com Online Giftshop Superstore http://www.cloudninegifts.com ==========================================================================
> On Sat, 9 Oct 1999, Bruce Momjian wrote: > > > Because the next release is going to probably be 7.0, if people have > > backward compatability library code that they have been dying to remove, > > this is the time for it. > > > > I don't recommend removing backward compatability with 6.4 or 6.5 > > releases, but if you have some code that is hanging around just to be > > compatible with 6.1 or earlier, I think it can be removed now. > > > > > > Then perhaps we can also overhaul the installation. I installed about > 5 times this past week and have it down to 4 or 5 steps (not including > regression testing). Great. That certainly needs a cleanup. My ideal would be to have a list of short instructions, and then have footnotes people would go to when they had a problem with a certain item. Not sure how to do that in sgml. If we did it in html, they could click on something when they had a problem, but html instructions are hard if you don't have a browser. -- Bruce Momjian | http://www.op.net/~candle maillist@candle.pha.pa.us | (610) 853-3000+ If your life is a hard drive, | 830 Blythe Avenue + Christ can be your backup. | Drexel Hill, Pennsylvania19026
Bruce Momjian wrote: > > Because the next release is going to probably be 7.0, if people have > backward compatability library code that they have been dying to remove, > this is the time for it. > > I don't recommend removing backward compatability with 6.4 or 6.5 > releases, but if you have some code that is hanging around just to be > compatible with 6.1 or earlier, I think it can be removed now. can the commands createuser and destroyuser be renamed to pg_createuser and pg_destroyuser (as pg_dump) adding soft links to preserve backwards compatibility (declaring previous commands deprecated) ? the same can be done for createdb and destroydb ... I think is a much more nice namespace for Postgres wich is important when you have thousands of commands in this times. -- | Sergio A. Kessler http://sak.org.ar -O_O- You can have it Soon, Cheap, and Working; choose *two*.
Yes, we have discussed this, and will add it to the TODO list. > Bruce Momjian wrote: > > > > Because the next release is going to probably be 7.0, if people have > > backward compatability library code that they have been dying to remove, > > this is the time for it. > > > > I don't recommend removing backward compatability with 6.4 or 6.5 > > releases, but if you have some code that is hanging around just to be > > compatible with 6.1 or earlier, I think it can be removed now. > > can the commands createuser and destroyuser be renamed to > pg_createuser and pg_destroyuser (as pg_dump) adding soft links to > preserve backwards compatibility (declaring previous commands > deprecated) ? > > the same can be done for createdb and destroydb ... > > I think is a much more nice namespace for Postgres wich is > important when you have thousands of commands in this times. > > -- > | Sergio A. Kessler http://sak.org.ar > -O_O- You can have it Soon, Cheap, and Working; choose *two*. > > ************ > -- Bruce Momjian | http://www.op.net/~candle maillist@candle.pha.pa.us | (610) 853-3000+ If your life is a hard drive, | 830 Blythe Avenue + Christ can be your backup. | Drexel Hill, Pennsylvania19026
> Yes, we have discussed this, and will add it to the TODO list.
> > can the commands createuser and destroyuser be renamed to
> > pg_createuser and pg_destroyuser (as pg_dump) adding soft links to
> > preserve backwards compatibility (declaring previous commands
> > deprecated) ?
> > the same can be done for createdb and destroydb ...
I hope we don't have a consensus on this. Long commands with
underscores in them are certainly another sign of the coming
apocalypse ;)
- Thomas
--
Thomas Lockhart lockhart@alumni.caltech.edu
South Pasadena, California
> > Yes, we have discussed this, and will add it to the TODO list. > > > can the commands createuser and destroyuser be renamed to > > > pg_createuser and pg_destroyuser (as pg_dump) adding soft links to > > > preserve backwards compatibility (declaring previous commands > > > deprecated) ? > > > the same can be done for createdb and destroydb ... > > I hope we don't have a consensus on this. Long commands with > underscores in them are certainly another sign of the coming > apocalypse ;) But if we keep symlinks to the existing names, is that OK? -- Bruce Momjian | http://www.op.net/~candle maillist@candle.pha.pa.us | (610) 853-3000+ If your life is a hard drive, | 830 Blythe Avenue + Christ can be your backup. | Drexel Hill, Pennsylvania19026
> I hope we don't have a consensus on this. Long commands with > underscores in them are certainly another sign of thecoming > apocalypse ;) But if we keep symlinks to the existing names, is that OK? Isn't the point to avoid naming conflicts. Symlinks won't help that, surely. I agree; underscores are a pain. If you must go this direction, I suggest hyphens (-). Cheers, Brook
> Then perhaps we can also overhaul the installation. I installed about > 5 times this past week and have it down to4 or 5 steps (not including > regression testing). Would this also be a relevant time to get a regression test to run on a non-installed system? Couldn't this be done by starting up the database on a different port from within the newly compiled source tree for the purpose of testing? Cheers, Brook
> > I hope we don't have a consensus on this. Long commands with > > underscores in them are certainly another sign of the coming > > apocalypse ;) > > But if we keep symlinks to the existing names, is that OK? > > Isn't the point to avoid naming conflicts. Symlinks won't help that, > surely. > > I agree; underscores are a pain. If you must go this direction, I > suggest hyphens (-). You could make the actual command pg_createuser, and make a symlink of createuser, but allow the symlink creation to fail. Best of both worlds, I think. I vote for underscore. That's what I normally use. Dashes look too much like command arguments. -- Bruce Momjian | http://www.op.net/~candle maillist@candle.pha.pa.us | (610) 853-3000+ If your life is a hard drive, | 830 Blythe Avenue + Christ can be your backup. | Drexel Hill, Pennsylvania19026
> > Then perhaps we can also overhaul the installation. I installed about > > 5 times this past week and have it down to 4 or 5 steps (not including > > regression testing). > > Would this also be a relevant time to get a regression test to run on > a non-installed system? Couldn't this be done by starting up the > database on a different port from within the newly compiled source > tree for the purpose of testing? Gee, I never even though of that. What advantage would there be for that? -- Bruce Momjian | http://www.op.net/~candle maillist@candle.pha.pa.us | (610) 853-3000+ If your life is a hard drive, | 830 Blythe Avenue + Christ can be your backup. | Drexel Hill, Pennsylvania19026
On Mon, 11 Oct 1999, Brook Milligan wrote: > Then perhaps we can also overhaul the installation. I installed about > 5 times this past week and have it down to 4 or 5 steps (not including > regression testing). > One thing I thought would be nice would be a client only install. Say I'm running a server on Solaris and want to make psql available on linux stations which will access the Solaris server. Right now, unless I've missed something, I'm stuck installing the whole package. No big problem but if you're overhaulling the install..... :-) Take Care, James ->->->->->->->->->->->->->->->->->->---<-<-<-<-<-<-<-<-<-<-<-<-<-<-<-<-<-< James Thompson 138 Cardwell Hall Manhattan, Ks 66506 785-532-0561 Kansas State University Department of Mathematics ->->->->->->->->->->->->->->->->->->---<-<-<-<-<-<-<-<-<-<-<-<-<-<-<-<-<-<
> Would this also be a relevant time to get a regression test to run on > a non-installed system? Couldn't this be doneby starting up the > database on a different port from within the newly compiled source > tree for the purpose of testing? Gee, I never even though of that. What advantage would there be for that? Wouldn't that be useful for developing/debugging/testing a new version on a machine that runs some other version in production mode? One example would be someone who wants to update, but wishes to verify the functioning of the new version prior to blowing away the old one. So, one could build the new version, run regression tests, resolve any issues, THEN deinstall the old version and install the new already verified one. Another example is that developers could use a production machine to tweak new code without having to actually install the test versions. I'm sure other applications of that flexibility are apparent also. Cheers, Brook
James Thompson wrote: > > One thing I thought would be nice would be a client only install. Say I'm > running a server on Solaris and want to make psql available on linux > stations which will access the Solaris server. Right now, unless I've > missed something, I'm stuck installing the whole package. No big problem > but if you're overhaulling the install..... :-) You can do that now with the RPM installation under RedHat Linux -- however, it is an RPM feature, not part of the tarball. Lamar Owen WGCR Internet Radio 1 Peter 4:11
Bruce Momjian <maillist@candle.pha.pa.us> writes:
>> Would this also be a relevant time to get a regression test to run on
>> a non-installed system?
> Gee, I never even though of that. What advantage would there be for
> that?
It has been suggested before, and I think it's a good idea. The
advantage is you can smoke-test a new compilation *before* you blow
away your existing installation ;-)
It is, of course, possible to do that by installing into a nonstandard
location/port and then running the regress tests there. But you have
to know exactly what you're doing to do that. If we're going to
overhaul install, we should make it easier to run the regress tests
that way, or even better with not-installed-at-all binaries from the
source tree.
Another thing I'd like to see would be full support for building in
a separate object-directory tree, leaving the source tree pristine
rather than filled with configure and build output files.
This is a standard GNU practice and I think it's a good one.
regards, tom lane
Brook Milligan wrote: > > > I hope we don't have a consensus on this. Long commands with > > underscores in them are certainly another sign of the coming > > apocalypse ;) > > But if we keep symlinks to the existing names, is that OK? > > Isn't the point to avoid naming conflicts. Symlinks won't help that, > surely. my suggestion was: in 7.0: provide symlinks for backward compatibility and make big warnings 'don't use createuser, etc. they are deprecated' all over the place ... in 7.1: remove the symlinks. > I agree; underscores are a pain. If you must go this direction, I > suggest hyphens (-). yup, but maybe (-) can rise problems in some filesystems ... (I certainly don't know) and more importantly you have then to rename pg_dump and pg_dumpall wich is the more heavily used command in scripts ... my idea was to leave this commands untouched. as for longnames that Thomas doesn't like (wich I don't agree because my idea for upgrading scripts is just: 'prepend a pg_ to the commands') what about pg_adduser, pg_deluser, pg_adddb, etc ? ;) -- | Sergio A. Kessler http://sak.org.ar -O_O- You can have it Soon, Cheap, and Working; choose *two*.
> my suggestion was: > in 7.0: provide symlinks for backward compatibility and make big > warnings 'don't use createuser, etc. they are deprecated' > all over the place ... > in 7.1: remove the symlinks. > > > I agree; underscores are a pain. If you must go this direction, I > > suggest hyphens (-). > > yup, but maybe (-) can rise problems in some filesystems ... > (I certainly don't know) > and more importantly you have then to rename pg_dump and pg_dumpall > wich is the more heavily used command in scripts ... > my idea was to leave this commands untouched. > > as for longnames that Thomas doesn't like (wich I don't agree because > my idea for upgrading scripts is just: 'prepend a pg_ to the commands') > what about pg_adduser, pg_deluser, pg_adddb, etc ? ;) That's a compromise. The destroy* entries are from the old quel days. Of course, that would make pg_deluser into pg_dropuser, but adddb would be createdb, and we are back were we started. :-) -- Bruce Momjian | http://www.op.net/~candle maillist@candle.pha.pa.us | (610) 853-3000+ If your life is a hard drive, | 830 Blythe Avenue + Christ can be your backup. | Drexel Hill, Pennsylvania19026
On Oct 11, Bruce Momjian mentioned: > > > Yes, we have discussed this, and will add it to the TODO list. > > > > can the commands createuser and destroyuser be renamed to > > > > pg_createuser and pg_destroyuser (as pg_dump) adding soft links to > > > > preserve backwards compatibility (declaring previous commands > > > > deprecated) ? > > > > the same can be done for createdb and destroydb ... > > > > I hope we don't have a consensus on this. Long commands with > > underscores in them are certainly another sign of the coming > > apocalypse ;) > > But if we keep symlinks to the existing names, is that OK? I think Thomas' primary problem was the underscore. (?) I was going to say that I can take of that, since I was going to adjust the scripts to play well with the new psql anyway. (In particular, I just terminally removed the -a option, since it has gone unused for a while and might be a very popular option switch in the future. Switches are becoming scarce these days.) I can offer the following plan (from my bin dir): cleardbdir --> (Remove. It's been a while.) createdb --> pgcreatedb createlang --> (In my excessively undereducated opinion, this should be removed. createdb and createuserI can see but this?) createuser --> pgcreateuser destroydb --> pgdestroydb destroylang --> (see above) destroyuser --> pgdestroyuser ecpg initdb --> pginitdb initlocation --> pginitlocation ipcclean --> pg_ipcclean (An underscore here to make it more complicated to type :) . . . vacuumdb --> pgvacuumdb Alternatively, there could also be shorter commands, now that the association with the PostgreSQL installation is clearer: pgcrdb pgcruser pgdestdb pgdestuser pgvacuum This might remove the mnemonic association with the related SQL commands (which some might find desirable). Some might also go for a set like this: pguseradd pguserdel pgmkdb pgrmdb in association to *nix commands. (Some might find that a bad idea). Furthermore I was thinking about a configure switch along the following lines: --enable-scripts=old|new|both|none (defaults to new) since a while back there was some talk about removing the scripts altogether (which also died after Thomas protested, I think). While we're at it, perhaps the scripts can also be moved around in the source tree, e.g., to bin/scripts or (if there will really be only 4 or 5) even into the psql subtree. Well, unless someone vetos, I would take a vote here and see what I can do. -Peter -- Peter Eisentraut Sernanders vaeg 10:115 peter_e@gmx.net 75262 Uppsala http://yi.org/peter-e/ Sweden
> I think Thomas' primary problem was the underscore. (?) OK. > > I was going to say that I can take of that, since I was going to adjust > the scripts to play well with the new psql anyway. (In particular, I just > terminally removed the -a option, since it has gone unused for a while and > might be a very popular option switch in the future. Switches are becoming > scarce these days.) > > I can offer the following plan (from my bin dir): > > cleardbdir --> (Remove. It's been a while.) Good. > createdb --> pgcreatedb Good. > createlang --> (In my excessively undereducated opinion, this should > be removed. createdb and createuser I can see but > this?) Yes, remove. What is that doing there. Jan's plpgsql doesn't use it. :-) > createuser --> pgcreateuser > destroydb --> pgdestroydb Can I recommend pgdropdb? > destroylang --> (see above) > destroyuser --> pgdestroyuser pgdropuser? > ecpg > initdb --> pginitdb > initlocation --> pginitlocation > ipcclean --> pg_ipcclean > (An underscore here to make it more complicated to type :) > . . . Not sure about that. > vacuumdb --> pgvacuumdb OK. > Alternatively, there could also be shorter commands, now that the > association with the PostgreSQL installation is clearer: > pgcrdb > pgcruser > pgdestdb > pgdestuser > pgvacuum Too cryptic for me. > This might remove the mnemonic association with the related SQL commands > (which some might find desirable). Some might also go for a set like this: > pguseradd > pguserdel > pgmkdb > pgrmdb > in association to *nix commands. (Some might find that a bad idea). Doesn't grab me. > > Furthermore I was thinking about a configure switch along the following > lines: > > --enable-scripts=old|new|both|none > (defaults to new) Too complicated. Issue a warning if invoked with old args and remove old link in 8.x. You can test basename $0 and test to see how you were invoked. > since a while back there was some talk about removing the scripts > altogether (which also died after Thomas protested, I think). I like the scripts too. -- Bruce Momjian | http://www.op.net/~candle maillist@candle.pha.pa.us | (610) 853-3000+ If your life is a hard drive, | 830 Blythe Avenue + Christ can be your backup. | Drexel Hill, Pennsylvania19026
Bruce Momjian wrote: > > createlang --> (In my excessively undereducated opinion, this should > > be removed. createdb and createuser I can see but > > this?) > > Yes, remove. What is that doing there. Jan's plpgsql doesn't use it. :-) Used by regression test script. No reason the script can't inline the createlang script's code, though. Lamar Owen WGCR Internet Radio 1 Peter 4:11
Re: Scripts (was Re: [HACKERS] Re: [INTERFACES] Next release is 7.0(?))
From
"Sergio A. Kessler"
Date:
Bruce Momjian wrote: > > > I think Thomas' primary problem was the underscore. (?) > > OK. hmmm, ok, not everyone can be totally happy ... please, Thomas, let us use the underscore so there no need to rename pg_dump and pg_dumpall pg_dump -> pg_dump pg_dumpall -> pg_dumpall createdb -> pg_createdb destroydb -> pg_dropdb createuser -> pg_createuser destroyuser -> pg_dropuser and prepend a 'pg_' to the rest I think it can't be more consistent that this... Thomas ?, please ? -- | Sergio A. Kessler http://sak.org.ar -O_O- You can have it Soon, Cheap, and Working; choose *two*.
On Mon, 11 Oct 1999, Thomas Lockhart wrote:
> > Yes, we have discussed this, and will add it to the TODO list.
> > > can the commands createuser and destroyuser be renamed to
> > > pg_createuser and pg_destroyuser (as pg_dump) adding soft links to
> > > preserve backwards compatibility (declaring previous commands
> > > deprecated) ?
> > > the same can be done for createdb and destroydb ...
>
> I hope we don't have a consensus on this. Long commands with
> underscores in them are certainly another sign of the coming
> apocalypse ;)
You'll get my agreement on this...but, then again, I'm advocating getting
rid of them altoghther and forcing the DBA to be forced to learn teh
proper commands...*shrug*
Marc G. Fournier ICQ#7615664 IRC Nick: Scrappy
Systems Administrator @ hub.org
primary: scrappy@hub.org secondary: scrappy@{freebsd|postgresql}.org
On Mon, 11 Oct 1999, Bruce Momjian wrote:
> > > Yes, we have discussed this, and will add it to the TODO list.
> > > > can the commands createuser and destroyuser be renamed to
> > > > pg_createuser and pg_destroyuser (as pg_dump) adding soft links to
> > > > preserve backwards compatibility (declaring previous commands
> > > > deprecated) ?
> > > > the same can be done for createdb and destroydb ...
> >
> > I hope we don't have a consensus on this. Long commands with
> > underscores in them are certainly another sign of the coming
> > apocalypse ;)
>
> But if we keep symlinks to the existing names, is that OK?
can we get rid of 'createdb/destroydb' and shorten them to:
'pg_adddb/pg_deldb' ... ? :)
Marc G. Fournier ICQ#7615664 IRC Nick: Scrappy
Systems Administrator @ hub.org
primary: scrappy@hub.org secondary: scrappy@{freebsd|postgresql}.org
On Mon, 11 Oct 1999, Bruce Momjian wrote:
> > > Yes, we have discussed this, and will add it to the TODO list.
> > > > can the commands createuser and destroyuser be renamed to
> > > > pg_createuser and pg_destroyuser (as pg_dump) adding soft links to
> > > > preserve backwards compatibility (declaring previous commands
> > > > deprecated) ?
> > > > the same can be done for createdb and destroydb ...
> >
> > I hope we don't have a consensus on this. Long commands with
> > underscores in them are certainly another sign of the coming
> > apocalypse ;)
>
> But if we keep symlinks to the existing names, is that OK?
Oh, and, IMHO...remove, don't create symlinks...its a major release, we
don't have to maintain backwards compatability...we aren't mIcrosoft, eh?
:)
Marc G. Fournier ICQ#7615664 IRC Nick: Scrappy
Systems Administrator @ hub.org
primary: scrappy@hub.org secondary: scrappy@{freebsd|postgresql}.org
Re: Scripts (was Re: [HACKERS] Re: [INTERFACES] Next release is 7.0(?))
From
The Hermit Hacker
Date:
Note: I still don't like the scripts...they create lazy, uneducated DBAs, of which I was one, since I didn't even *know* there were internal commands that did more then the external ones did, for the longest time... Personally, those scripts should jsut become: try 'create user' from psql interface *grump look* On Mon, 11 Oct 1999, Bruce Momjian wrote: > > I think Thomas' primary problem was the underscore. (?) > > OK. > > > > > I was going to say that I can take of that, since I was going to adjust > > the scripts to play well with the new psql anyway. (In particular, I just > > terminally removed the -a option, since it has gone unused for a while and > > might be a very popular option switch in the future. Switches are becoming > > scarce these days.) > > > > I can offer the following plan (from my bin dir): > > > > cleardbdir --> (Remove. It's been a while.) > > Good. > > > createdb --> pgcreatedb > > Good. > > > createlang --> (In my excessively undereducated opinion, this should > > be removed. createdb and createuser I can see but > > this?) > > Yes, remove. What is that doing there. Jan's plpgsql doesn't use it. :-) > > > createuser --> pgcreateuser > > destroydb --> pgdestroydb > > Can I recommend pgdropdb? > > > destroylang --> (see above) > > destroyuser --> pgdestroyuser > > pgdropuser? > > > ecpg > > initdb --> pginitdb > > initlocation --> pginitlocation > > ipcclean --> pg_ipcclean > > (An underscore here to make it more complicated to type :) > > . . . > > Not sure about that. > > > vacuumdb --> pgvacuumdb > > OK. > > > Alternatively, there could also be shorter commands, now that the > > association with the PostgreSQL installation is clearer: > > pgcrdb > > pgcruser > > pgdestdb > > pgdestuser > > pgvacuum > > Too cryptic for me. > > > This might remove the mnemonic association with the related SQL commands > > (which some might find desirable). Some might also go for a set like this: > > pguseradd > > pguserdel > > pgmkdb > > pgrmdb > > in association to *nix commands. (Some might find that a bad idea). > > Doesn't grab me. > > > > > Furthermore I was thinking about a configure switch along the following > > lines: > > > > --enable-scripts=old|new|both|none > > (defaults to new) > > Too complicated. Issue a warning if invoked with old args and remove > old link in 8.x. You can test basename $0 and test to see how you were > invoked. > > > > since a while back there was some talk about removing the scripts > > altogether (which also died after Thomas protested, I think). > > I like the scripts too. > > -- > Bruce Momjian | http://www.op.net/~candle > maillist@candle.pha.pa.us | (610) 853-3000 > + If your life is a hard drive, | 830 Blythe Avenue > + Christ can be your backup. | Drexel Hill, Pennsylvania 19026 > > ************ > Marc G. Fournier ICQ#7615664 IRC Nick: Scrappy Systems Administrator @ hub.org primary: scrappy@hub.org secondary: scrappy@{freebsd|postgresql}.org
Re: Scripts (was Re: [HACKERS] Re: [INTERFACES] Next release is
From
wieck@debis.com (Jan Wieck)
Date:
> > > in association to *nix commands. (Some might find that a bad idea).
Then it MUST be pgcreatuser!
Jan
--
#======================================================================#
# It's easier to get forgiveness for being wrong than for being right. #
# Let's break this rule - forgive me. #
#========================================= wieck@debis.com (Jan Wieck) #
> > > I hope we don't have a consensus on this. Long commands with > > > underscores in them are certainly another sign of the coming > > > apocalypse ;) > > > > But if we keep symlinks to the existing names, is that OK? > > Oh, and, IMHO...remove, don't create symlinks...its a major release, we > don't have to maintain backwards compatability...we aren't mIcrosoft, eh? > :) That is a good point. We could remove them. They don't get called very often. -- Bruce Momjian | http://www.op.net/~candle maillist@candle.pha.pa.us | (610) 853-3000+ If your life is a hard drive, | 830 Blythe Avenue + Christ can be your backup. | Drexel Hill, Pennsylvania19026
On 11-Oct-99 Bruce Momjian wrote:
> You could make the actual command pg_createuser, and make a symlink of
> createuser, but allow the symlink creation to fail. Best of both
> worlds, I think. I vote for underscore. That's what I normally use.
> Dashes look too much like command arguments.
Agreed. I don't like underscores, but hyphens can be worse.
I think the best idea is to use a name that identifies the script as
being a part of PostgreSQL, and can somehow clearly define what the
script is designed to do, and then whatever you choose, _stick_with_it_!
System administrators and programmers can make symbolic links if they
need them.
----------------------------------
Date: 12-Oct-99 Time: 16:10:10
Craig Orsinger (email: <orsingerc@epg-gw1.lewis.army.mil>)
Logicon RDA
Bldg. 8B28 "Just another megalomaniac with ideas above his
6th & F Streets station. The Universe is full of them."
Ft. Lewis, WA 98433 - The Doctor
----------------------------------
Re: Scripts (was Re: [HACKERS] Re: [INTERFACES] Next release is 7.0(?))
From
wieck@debis.com (Jan Wieck)
Date:
Lamar Owen wrote:
>
> Bruce Momjian wrote:
> > > createlang --> (In my excessively undereducated opinion, this should
> > > be removed. createdb and createuser I can see but
> > > this?)
> >
> > Yes, remove. What is that doing there. Jan's plpgsql doesn't use it. :-)
>
> Used by regression test script. No reason the script can't inline the
> createlang script's code, though.
That script was the result of some longer discussion about
"installing PL/pgSQL by default (initdb) or not" which
resulted from some problems with the location of the language
handler object.
Some people like to have one or the other language in
template1, so it will automatically be there after createdb.
Others like to install individual PL's per database.
What I see from your comments above is, that you don't use
procedural languages at all. But that's not a good reason for
making it harder for others to gain access to these
languages.
Jan
--
#======================================================================#
# It's easier to get forgiveness for being wrong than for being right. #
# Let's break this rule - forgive me. #
#========================================= wieck@debis.com (Jan Wieck) #