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, Pennsylvania 19026

Sat, 9 Oct 1999 08:53:22 -0400 (EDT)
Bruce Momjian <maillist@candle.pha.pa.us>
Next release is 7.0(?)
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 seen http://www.pop4.net?
        Online Campground Directory    http://www.camping-usa.com
       Online Giftshop Superstore    http://www.cloudninegifts.com
==========================================================================




Sat, 9 Oct 1999 09:03:09 -0400 (EDT)
Vince Vielhaber <vev@michvhf.com>
Re: [HACKERS] Next release is 7.0(?)
> 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, Pennsylvania 19026

Sat, 9 Oct 1999 16:21:56 -0400 (EDT)
Bruce Momjian <maillist@candle.pha.pa.us>
Re: [HACKERS] Next release is 7.0(?)
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*.

Sun, 10 Oct 1999 15:01:03 -0300
"Sergio A. Kessler" <ser@perio.unlp.edu.ar>
Re: [INTERFACES] Next release is 7.0(?)
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, Pennsylvania 19026

Sun, 10 Oct 1999 16:39:55 -0400 (EDT)
Bruce Momjian <maillist@candle.pha.pa.us>
Re: [HACKERS] Re: [INTERFACES] Next release is 7.0(?)
> 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

Mon, 11 Oct 1999 15:17:46 +0000
Thomas Lockhart <lockhart@alumni.caltech.edu>
Re: [HACKERS] Re: [INTERFACES] Next release is 7.0(?)
> > 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, Pennsylvania 19026

Mon, 11 Oct 1999 11:43:33 -0400 (EDT)
Bruce Momjian <maillist@candle.pha.pa.us>
Re: [HACKERS] Re: [INTERFACES] Next release is 7.0(?)
   > 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 (-).

Cheers,
Brook

Mon, 11 Oct 1999 10:56:30 -0600 (MDT)
Brook Milligan <brook@biology.nmsu.edu>
Re: [HACKERS] Re: [INTERFACES] Next release is 7.0(?)
   > 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?

Cheers,
Brook

Mon, 11 Oct 1999 10:58:14 -0600 (MDT)
Brook Milligan <brook@biology.nmsu.edu>
Re: [HACKERS] Next release is 7.0(?)
>    > 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, Pennsylvania 19026

Mon, 11 Oct 1999 13:04:56 -0400 (EDT)
Bruce Momjian <maillist@candle.pha.pa.us>
Re: [HACKERS] Re: [INTERFACES] Next release is 7.0(?)
>    > 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, Pennsylvania 19026

Mon, 11 Oct 1999 13:05:24 -0400 (EDT)
Bruce Momjian <maillist@candle.pha.pa.us>
Re: [HACKERS] Next release is 7.0(?)
   > 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?

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

Mon, 11 Oct 1999 12:05:42 -0600 (MDT)
Brook Milligan <brook@biology.nmsu.edu>
Re: [HACKERS] Next release is 7.0(?)
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
->->->->->->->->->->->->->->->->->->---<-<-<-<-<-<-<-<-<-<-<-<-<-<-<-<-<-<



Mon, 11 Oct 1999 13:06:02 -0500 (CDT)
James Thompson <jamest@math.ksu.edu>
Re: [HACKERS] Next release is 7.0(?)
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

Mon, 11 Oct 1999 14:32:26 -0400
Lamar Owen <lamar.owen@wgcr.org>
Re: [HACKERS] Next release is 7.0(?)
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

Mon, 11 Oct 1999 14:57:25 -0400
Tom Lane <tgl@sss.pgh.pa.us>
Re: [HACKERS] Next release is 7.0(?) 
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*.

Mon, 11 Oct 1999 17:31:36 -0300
"Sergio A. Kessler" <ser@perio.unlp.edu.ar>
Re: [HACKERS] Re: [INTERFACES] Next release is 7.0(?)
> 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, Pennsylvania 19026

Mon, 11 Oct 1999 16:51:46 -0400 (EDT)
Bruce Momjian <maillist@candle.pha.pa.us>
Re: [HACKERS] Re: [INTERFACES] Next release is 7.0(?)
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 createuser I 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


Mon, 11 Oct 1999 22:57:51 +0200 (CEST)
Peter Eisentraut <peter_e@gmx.net>
Scripts (was Re: [HACKERS] Re: [INTERFACES] Next release is 7.0(?))
> 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

Mon, 11 Oct 1999 18:24:17 -0400 (EDT)
Bruce Momjian <maillist@candle.pha.pa.us>
Re: Scripts (was Re: [HACKERS] Re: [INTERFACES] Next release is
	7.0(?))
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

Mon, 11 Oct 1999 18:59:45 -0400
Lamar Owen <lamar.owen@wgcr.org>
Re: Scripts (was Re: [HACKERS] Re: [INTERFACES] Next release is
	7.0(?))
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*.

Tue, 12 Oct 1999 00:12:25 -0300
"Sergio A. Kessler" <ser@perio.unlp.edu.ar>
Re: Scripts (was Re: [HACKERS] Re: [INTERFACES] Next release is
	7.0(?))
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 


Tue, 12 Oct 1999 01:16:26 -0300 (ADT)
The Hermit Hacker <scrappy@hub.org>
Re: [HACKERS] Re: [INTERFACES] Next release is 7.0(?)
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 


Tue, 12 Oct 1999 01:17:22 -0300 (ADT)
The Hermit Hacker <scrappy@hub.org>
Re: [HACKERS] Re: [INTERFACES] Next release is 7.0(?)
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 


Tue, 12 Oct 1999 01:18:04 -0300 (ADT)
The Hermit Hacker <scrappy@hub.org>
Re: [HACKERS] Re: [INTERFACES] Next release is 7.0(?)

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 


Tue, 12 Oct 1999 01:22:36 -0300 (ADT)
The Hermit Hacker <scrappy@hub.org>
Re: Scripts (was Re: [HACKERS] Re: [INTERFACES] Next release is
	7.0(?))
> > > 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) #


Tue, 12 Oct 1999 11:12:11 +0200 (MET DST)
wieck@debis.com (Jan Wieck)
Re: Scripts (was Re: [HACKERS] Re: [INTERFACES] Next release is
> > > 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, Pennsylvania 19026

Tue, 12 Oct 1999 09:58:42 -0400 (EDT)
Bruce Momjian <maillist@candle.pha.pa.us>
Re: [HACKERS] Re: [INTERFACES] Next release is 7.0(?)

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

Tue, 12 Oct 1999 16:13:48 -0700 (PDT)
Craig Orsinger <orsingerc@epg-gw1.lewis.army.mil>
Re: [HACKERS] Re: [INTERFACES] Next release is 7.0(?)
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) #



Fri, 15 Oct 1999 13:54:11 +0200 (MET DST)
wieck@debis.com (Jan Wieck)
Re: Scripts (was Re: [HACKERS] Re: [INTERFACES] Next release is
	7.0(?))