Thread: Next release is 7.0(?)

Next release is 7.0(?)

From
Bruce Momjian
Date:
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
 


Re: [INTERFACES] Next release is 7.0(?)

From
"Sergio A. Kessler"
Date:
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*.


Re: [HACKERS] Re: [INTERFACES] Next release is 7.0(?)

From
Bruce Momjian
Date:
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
 


Re: [HACKERS] Re: [INTERFACES] Next release is 7.0(?)

From
Thomas Lockhart
Date:
> 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


Re: [HACKERS] Re: [INTERFACES] Next release is 7.0(?)

From
Bruce Momjian
Date:
> > 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
 


Re: [HACKERS] Re: [INTERFACES] Next release is 7.0(?)

From
Brook Milligan
Date:
> 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


Re: [HACKERS] Re: [INTERFACES] Next release is 7.0(?)

From
Bruce Momjian
Date:
>    > 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
 


Re: [HACKERS] Re: [INTERFACES] Next release is 7.0(?)

From
"Sergio A. Kessler"
Date:
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*.


Re: [HACKERS] Re: [INTERFACES] Next release is 7.0(?)

From
Bruce Momjian
Date:
> 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
 


Scripts (was Re: [HACKERS] Re: [INTERFACES] Next release is 7.0(?))

From
Peter Eisentraut
Date:
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



Re: Scripts (was Re: [HACKERS] Re: [INTERFACES] Next release is 7.0(?))

From
Bruce Momjian
Date:
> 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
 


Re: Scripts (was Re: [HACKERS] Re: [INTERFACES] Next release is 7.0(?))

From
Lamar Owen
Date:
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*.


Re: [HACKERS] Re: [INTERFACES] Next release is 7.0(?)

From
The Hermit Hacker
Date:
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 



Re: [HACKERS] Re: [INTERFACES] Next release is 7.0(?)

From
The Hermit Hacker
Date:
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 



Re: [HACKERS] Re: [INTERFACES] Next release is 7.0(?)

From
The Hermit Hacker
Date:
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) #

Re: [HACKERS] Re: [INTERFACES] Next release is 7.0(?)

From
Bruce Momjian
Date:
> > > 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
 


Re: [HACKERS] Re: [INTERFACES] Next release is 7.0(?)

From
Craig Orsinger
Date:
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) #