Thread

Re: [HACKERS] Re: HISTORY for 6.5.2

Tom Lane <tgl@sss.pgh.pa.us> — 1999-09-18T21:00:41Z

Lamar Owen <lamar.owen@wgcr.org> writes:
> So, it IS an interesting thought -- while it would initially create a
> good deal of confusion, what is the consensus of the hackers on this
> issue??  Prepending "pg_" to all postgresql commands seems to me to be
> a good idea (after all, we already hav pg_dump, pg_dumpall,
> pg_upgrade, etc.).

I don't see a need to change the names of psql or ecpg, which just
happen to be the things most commonly invoked by users.  I'd be in favor
of prepending pg_ to all the "admin-type" commands like createuser.
Especially the createXXX/destroyXXX/initXXX ones, which seem the most
likely to cause naming conflicts.

While we are thinking about this, I wonder if it wouldn't be a good idea
to separate out the executables that aren't really intended to be
executed willy-nilly, and put them in a different directory.
postmaster, postgres, and initdb have no business being in users' PATH
at all, ever.  You could make a case that some of the other executables
are admin tools not intended for ordinary mortals, as well, and should
not live in a directory that might be put in users' PATH.

Of course, the other way an admin can handle that issue is not to put
/usr/local/pgsql/bin into PATH, but to make symlinks from a more popular
directory (say, /usr/local/bin) for the programs that users are expected
to execute.  I suppose such an admin could stick pg_ on the front of the
symlinks anyway.  But then the program names don't match the
documentation we supply, which would be confusing.

			regards, tom lane

Re: [HACKERS] Re: HISTORY for 6.5.2

Lamar Owen <lamar.owen@wgcr.org> — 1999-09-18T21:15:07Z

On Sat, 18 Sep 1999, Tom Lane wrote:
> While we are thinking about this, I wonder if it wouldn't be a good idea
> to separate out the executables that aren't really intended to be
> executed willy-nilly, and put them in a different directory.
> postmaster, postgres, and initdb have no business being in users' PATH
> at all, ever. 

Such as /usr/sbin on a Linux FSSTND-compliant system (such as RedHat).  In
fact, I may just do that with the RPM distribution (after consulting with RedHat
on the issue).  Thomas??  The same goes for the admin commands' man pages --
they should be in section 8 on the typical Linux box.

> to execute.  I suppose such an admin could stick pg_ on the front of the
> symlinks anyway.  But then the program names don't match the
> documentation we supply, which would be confusing.

Well, as things stand, the documentation and the rpm distribution don't match
in other areas -- I personally would have absolutely no problem whatsoever in
doing such a renaming -- hey, I can do such inside the RPM, for that matter,
but I don't want to.  Of course, I would follow whatever the core group decides
-- that is the standard.  I'm just tossing ideas.

Lamar Owen
WGCR Internet Radio

Re: [HACKERS] Re: HISTORY for 6.5.2

Bruce Momjian <maillist@candle.pha.pa.us> — 1999-09-18T21:38:16Z

> Lamar Owen <lamar.owen@wgcr.org> writes:
> > So, it IS an interesting thought -- while it would initially create a
> > good deal of confusion, what is the consensus of the hackers on this
> > issue??  Prepending "pg_" to all postgresql commands seems to me to be
> > a good idea (after all, we already hav pg_dump, pg_dumpall,
> > pg_upgrade, etc.).
> 
> I don't see a need to change the names of psql or ecpg, which just
> happen to be the things most commonly invoked by users.  I'd be in favor
> of prepending pg_ to all the "admin-type" commands like createuser.
> Especially the createXXX/destroyXXX/initXXX ones, which seem the most
> likely to cause naming conflicts.

I have been thinking, the destroy should be drop, in keeping with SQL. 
destroy was a QUEL'ism.


> While we are thinking about this, I wonder if it wouldn't be a good idea
> to separate out the executables that aren't really intended to be
> executed willy-nilly, and put them in a different directory.
> postmaster, postgres, and initdb have no business being in users' PATH
> at all, ever.  You could make a case that some of the other executables
> are admin tools not intended for ordinary mortals, as well, and should
> not live in a directory that might be put in users' PATH.

Seems like it could make it harder for newbies.

> Of course, the other way an admin can handle that issue is not to put
> /usr/local/pgsql/bin into PATH, but to make symlinks from a more popular
> directory (say, /usr/local/bin) for the programs that users are expected
> to execute.  I suppose such an admin could stick pg_ on the front of the
> symlinks anyway.  But then the program names don't match the
> documentation we supply, which would be confusing.


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

Re: [HACKERS] Re: HISTORY for 6.5.2

Michael Alan Dorman <mdorman@debian.org> — 1999-09-18T22:38:55Z

Lamar Owen <lamar.owen@wgcr.org> writes:
> Such as /usr/sbin on a Linux FSSTND-compliant system (such as RedHat).  In
> fact, I may just do that with the RPM distribution (after consulting with RedHat
> on the issue).

Actually, I would even advocate what GNU configure calls the "libexec"
directory---a directory like /usr/lib/emacs/i386-linux, which has
movemail and a couple of other things that aren't meant to be run by
users, but invoked by other programs.

Mike.

Re: [HACKERS] Re: HISTORY for 6.5.2

Thomas Lockhart <lockhart@alumni.caltech.edu> — 1999-09-19T05:51:22Z

> > While we are thinking about this, I wonder if it wouldn't be a good idea
> > to separate out the executables that aren't really intended to be
> > executed willy-nilly, and put them in a different directory.
> > postmaster, postgres, and initdb have no business being in users' PATH
> > at all, ever.
> Such as /usr/sbin on a Linux FSSTND-compliant system (such as RedHat).  In
> fact, I may just do that with the RPM distribution (after consulting with RedHat
> on the issue).  Thomas??  The same goes for the admin commands' man pages --
> they should be in section 8 on the typical Linux box.

Man page sections can be reassigned for the next release. afaik
/usr/sbin tends to contain programs executed by root, which is not
usually the case for Postgres. Is there a precedent for other programs
of this type in that directory?

> > I suppose such an admin could stick pg_ on the front of the
> > symlinks anyway.  But then the program names don't match the
> > documentation we supply, which would be confusing.

Underscores in program names suck. To paraphrase Ali, "no opinion,
just fact" ;) 

If we are going to rename programs wholesale, let's do it for release
7.0, and if we must have "pg" in front of everything, then do it as,
e.g. "pgcreateuser". We could rename "pg_dump" as "pgdump" at the same
time.

btw, is it only me or do other people refer to this as "pig dump"?

> Well, as things stand, the documentation and the rpm distribution don't match
> in other areas -- I personally would have absolutely no problem whatsoever in
> doing such a renaming -- hey, I can do such inside the RPM, for that matter,
> but I don't want to.  Of course, I would follow whatever the core group decides
> -- that is the standard.  I'm just tossing ideas.

The docs don't claim to match the rpm (or any other real system; as
the intro claims it is just used as an example). The docs *do* claim
to know about what program you should run, so those names should never
change unless done in the official distro.

                       - Thomas

-- 
Thomas Lockhart				lockhart@alumni.caltech.edu
South Pasadena, California

Re: [HACKERS] Re: HISTORY for 6.5.2

Michael Simms <grim@argh.demon.co.uk> — 1999-09-19T06:14:57Z

> > on the issue).  Thomas??  The same goes for the admin commands' man pages --
> > they should be in section 8 on the typical Linux box.
> 
> Man page sections can be reassigned for the next release. afaik
> /usr/sbin tends to contain programs executed by root, which is not
> usually the case for Postgres. Is there a precedent for other programs
> of this type in that directory?

IIRC majordomo puts the whole slew of commands in the same directory, usually
/usr/local/bin when you install it. Most of these are not really user commands

> btw, is it only me or do other people refer to this as "pig dump"?

I try and steer clear of pig dump in all its forms {;-)

						~Michael

Re: [HACKERS] Re: HISTORY for 6.5.2

Lamar Owen <lamar.owen@wgcr.org> — 1999-09-19T19:33:21Z

On Sun, 19 Sep 1999, Thomas Lockhart wrote:
> > Such as /usr/sbin on a Linux FSSTND-compliant system (such as RedHat).  In
> > fact, I may just do that with the RPM distribution (after consulting with RedHat
> > on the issue).  Thomas??  The same goes for the admin commands' man pages --
> > they should be in section 8 on the typical Linux box.
> 
> Man page sections can be reassigned for the next release. afaik
> /usr/sbin tends to contain programs executed by root, which is not
> usually the case for Postgres. Is there a precedent for other programs
> of this type in that directory?

The uucp programs uuxqt and uucico live in /usr/sbin (on RedHat 6).  They are
owned by and executed as user uucp. See other message for FHS quote re:
/usr/sbin.

> Underscores in program names suck. To paraphrase Ali, "no opinion,
> just fact" ;) 

I thought VACUUM sucked.... ;-P  In all seriousness, I totally agree -- either
replace the _ with -, or drop it altogether.

> If we are going to rename programs wholesale, let's do it for release
> 7.0, and if we must have "pg" in front of everything, then do it as,
> e.g. "pgcreateuser". We could rename "pg_dump" as "pgdump" at the same
> time.

Sounds good to me.

> btw, is it only me or do other people refer to this as "pig dump"?

Worse -- I see '/usr/lib/pgsql' and say "user-lib-pigsqueal."

So, with have a var-lib-pigsqueal, user-lib-pigsqueal, and a
user-local-pigsqueal.  Yuck.

> The docs don't claim to match the rpm (or any other real system; as
> the intro claims it is just used as an example). The docs *do* claim
> to know about what program you should run, so those names should never
> change unless done in the official distro.

Agreed.  Like I said, I'm just tossing some ideas -- if they make it in, Ok, if
not, Ok.  As far as I am concerned, it really doesn't matter -- RedHat has
never had a namespace conflict with the PostgreSQL executables residing in
/usr/bin.  The only advantage I see is removing certain admin commands from the
standard PATH.  Then, for user postgres, add to PATH the admin commands'
residence.  Make it part of the .profile for user postgres, give postgres a
different home (under RedHat, ~postgres is currently /var/lib/pgsql), and things
should work fine.

Lamar Owen
WGCR Internet Radio

Re: [HACKERS] Re: HISTORY for 6.5.2

Bernard Adrian Frankpitt <frankpit@pop.dn.net> — 1999-09-19T20:13:28Z

Lamar Owen wrote:

> > btw, is it only me or do other people refer to this as "pig dump"?
> 
> Worse -- I see '/usr/lib/pgsql' and say "user-lib-pigsqueal."
> 

The first time my wife, saw the title of this mail-list she pronounced
pgsql `pig squeal', and was rather upset at the thought of
pgsql-hackers.  

Bernie Frankpitt

Re: [HACKERS] Re: HISTORY for 6.5.2

Dmitry Samersoff <dms@wplus.net> — 1999-09-20T05:53:29Z

On 19-Sep-99 frankpit@pop.dn.net wrote:
> Lamar Owen wrote:
> 
> 
>> > btw, is it only me or do other people refer to this as "pig dump"?
>> 
>> Worse -- I see '/usr/lib/pgsql' and say "user-lib-pigsqueal."
>> 
> 
> The first time my wife, saw the title of this mail-list she pronounced
> pgsql `pig squeal', and was rather upset at the thought of
         ^^^^^^^^^^^
   It's good reason to change postgres's logo - I'can remade site in
pig's colors ;-))))


---
Dmitry Samersoff, dms@wplus.net, ICQ:3161705
http://devnull.wplus.net
* There will come soft rains ...

Re: [HACKERS] Re: HISTORY for 6.5.2

Theo Kramer <theo@flame.co.za> — 1999-09-20T07:28:40Z

Thomas Lockhart wrote:
> Underscores in program names suck. To paraphrase Ali, "no opinion,
> just fact" ;)
> 
> If we are going to rename programs wholesale, let's do it for release
> 7.0, and if we must have "pg" in front of everything, then do it as,
> e.g. "pgcreateuser". We could rename "pg_dump" as "pgdump" at the same
> time.

I agree regarding the underscore. I do think that changing the names
sooner would create less hassle in the long run. Especially now when
more and more folk are starting to use postgres.

> btw, is it only me or do other people refer to this as "pig dump"?

grunt :-)
 
--------
Regards
Theo

Re: [HACKERS] Re: HISTORY for 6.5.2

Brook Milligan <brook@biology.nmsu.edu> — 1999-09-20T16:19:49Z

   IIRC majordomo puts the whole slew of commands in the same directory, usually
   /usr/local/bin when you install it. Most of these are not really user commands

Majordomo isn't really the best standard for installation
directories.  Please do not follow it as a general guideline.

Cheers,
Brook

Re: [HACKERS] Re: HISTORY for 6.5.2

Marc G. Fournier <scrappy@hub.org> — 1999-09-20T21:36:32Z

On Sat, 18 Sep 1999, Bruce Momjian wrote:

> I have been thinking, the destroy should be drop, in keeping with SQL. 
> destroy was a QUEL'ism.

{create,destroy}{user,db} should be drop'd, personally...admins should use
the SQL commands directly...

Marc G. Fournier                   ICQ#7615664               IRC Nick: Scrappy
Systems Administrator @ hub.org 
primary: scrappy@hub.org           secondary: scrappy@{freebsd|postgresql}.org

Re: [HACKERS] Re: HISTORY for 6.5.2

Vince Vielhaber <vev@michvhf.com> — 1999-09-20T22:18:15Z

On 20-Sep-99 The Hermit Hacker wrote:
> On Sat, 18 Sep 1999, Bruce Momjian wrote:
> 
>> I have been thinking, the destroy should be drop, in keeping with SQL. 
>> destroy was a QUEL'ism.
> 
> {create,destroy}{user,db} should be drop'd, personally...admins should use
> the SQL commands directly...

I think it'd be better if they were kept.  They're really convenient for
the newbie (I just introduced someone to PostgreSQL and all the way thru
were references to MySQL, including the create user, db, etc. scripts).

Vince.
-- 
==========================================================================
Vince Vielhaber -- KA8CSH   email: vev@michvhf.com   flame-mail: /dev/null
       # include <std/disclaimers.h>                   TEAM-OS2
        Online Campground Directory    http://www.camping-usa.com
       Online Giftshop Superstore    http://www.cloudninegifts.com
==========================================================================

Re: [HACKERS] Re: HISTORY for 6.5.2

Marc G. Fournier <scrappy@hub.org> — 1999-09-20T22:26:29Z

On Mon, 20 Sep 1999, Vince Vielhaber wrote:

> 
> On 20-Sep-99 The Hermit Hacker wrote:
> > On Sat, 18 Sep 1999, Bruce Momjian wrote:
> > 
> >> I have been thinking, the destroy should be drop, in keeping with SQL. 
> >> destroy was a QUEL'ism.
> > 
> > {create,destroy}{user,db} should be drop'd, personally...admins should use
> > the SQL commands directly...
> 
> I think it'd be better if they were kept.  They're really convenient for
> the newbie (I just introduced someone to PostgreSQL and all the way thru
> were references to MySQL, including the create user, db, etc. scripts).

My personal dislike for them is that they are incomplete...CREATE USER and
CREATE DATABASE  have a helluva lot of options available to it...using
createuser, you don't know/learn abotu them...

Force the admin to learn what they are doing...if they want to create
short cut scripts, let *them* do it...

Marc G. Fournier                   ICQ#7615664               IRC Nick: Scrappy
Systems Administrator @ hub.org 
primary: scrappy@hub.org           secondary: scrappy@{freebsd|postgresql}.org

Re: [HACKERS] Re: HISTORY for 6.5.2

Bruce Momjian <maillist@candle.pha.pa.us> — 1999-09-20T22:46:33Z

> My personal dislike for them is that they are incomplete...CREATE USER and
> CREATE DATABASE  have a helluva lot of options available to it...using
> createuser, you don't know/learn abotu them...
> 
> Force the admin to learn what they are doing...if they want to create
> short cut scripts, let *them* do it...

But newbies can't do shortcuts.  I think we need to keep it.

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

Re: [HACKERS] Re: HISTORY for 6.5.2

Yu Cao <yucao@falcon.kla-tencor.com> — 1999-09-20T22:47:16Z

I think I can safely speak for a newbie and I happen to dislike
createdb etc as well. I started out with postgreSQL with the
intention of writing an application-specific CORBA front-end
to it, so I cared most about the C++ interface. The existence of
the createdb command confused me for a while, leaving me thinking
I could do INSERT and SELECT etc from libpq++, but would have
to resort to UNIX calls to do createdb. 

--Yu Cao

On Mon, 20 Sep 1999, The Hermit Hacker wrote:

> On Mon, 20 Sep 1999, Vince Vielhaber wrote:
> 
> > 
> > On 20-Sep-99 The Hermit Hacker wrote:
> > > On Sat, 18 Sep 1999, Bruce Momjian wrote:
> > > 
> > >> I have been thinking, the destroy should be drop, in keeping with SQL. 
> > >> destroy was a QUEL'ism.
> > > 
> > > {create,destroy}{user,db} should be drop'd, personally...admins should use
> > > the SQL commands directly...
> > 
> > I think it'd be better if they were kept.  They're really convenient for
> > the newbie (I just introduced someone to PostgreSQL and all the way thru
> > were references to MySQL, including the create user, db, etc. scripts).
> 
> My personal dislike for them is that they are incomplete...CREATE USER and
> CREATE DATABASE  have a helluva lot of options available to it...using
> createuser, you don't know/learn abotu them...
> 
> Force the admin to learn what they are doing...if they want to create
> short cut scripts, let *them* do it...

Re: [HACKERS] Re: HISTORY for 6.5.2

Michael Simms <grim@argh.demon.co.uk> — 1999-09-20T23:20:21Z

> I think I can safely speak for a newbie and I happen to dislike
> createdb etc as well. I started out with postgreSQL with the
> intention of writing an application-specific CORBA front-end
> to it, so I cared most about the C++ interface. The existence of
> the createdb command confused me for a while, leaving me thinking
> I could do INSERT and SELECT etc from libpq++, but would have
> to resort to UNIX calls to do createdb. 
> 
> --Yu Cao
> 

I would have to say that if you 'started out with theintention of writing
a corba front-and' then I dont think you can really speak for newbies.

When I started using postgresql I had vaguely heard of odbc and I had
a couple of example queries of SQL.

If I had had to go to template1 and create database whatever; and THEN
go use it, I would have been fairly confused.

The way I look at it, it is functionality that is THERE already. If you
remove it, you remove from the overall functionality of postgres. It doesnt
actually gain anything to remove it. Sure it looks a bit neater, but the end
user cares about being able to use it easilly, not if the scripts are
technically pleasing.

I think the problem described above comes from a lack in the documentation,
or a failure to read the relavent documentation. Having more functionality
is good. Removing it is counterproductive.

The arguement that was put forwards of 'if they want scripts they can write
them, let the admins learn and do it themselves' is a bad one IMHO. Is
it really desirable for a dozen people to be forced to write what is
effectively the same script? When the script is already there anyway?
We should be moving towards a lower learning curve to getting a basic
database up and running, not a higher one. Not all the users WANT to
have to write theirown scripts for everything. I know I certainly
dont.

Just my 2p worth

						~Michael

Re: [HACKERS] Re: HISTORY for 6.5.2

Marc G. Fournier <scrappy@hub.org> — 1999-09-21T01:26:42Z

On Mon, 20 Sep 1999, Bruce Momjian wrote:

> > My personal dislike for them is that they are incomplete...CREATE USER and
> > CREATE DATABASE  have a helluva lot of options available to it...using
> > createuser, you don't know/learn abotu them...
> > 
> > Force the admin to learn what they are doing...if they want to create
> > short cut scripts, let *them* do it...
> 
> But newbies can't do shortcuts.  I think we need to keep it.

Newbies can't read man pages to type 'CREATE USER <userid>' or 'CREATE
DATABASE <database>'?

We're not asking anyone to learn rocket science here...we leave that to
Thomas :)

Marc G. Fournier                   ICQ#7615664               IRC Nick: Scrappy
Systems Administrator @ hub.org 
primary: scrappy@hub.org           secondary: scrappy@{freebsd|postgresql}.org

Re: [HACKERS] Re: HISTORY for 6.5.2

Marc G. Fournier <scrappy@hub.org> — 1999-09-21T01:44:04Z

On Tue, 21 Sep 1999, Michael Simms wrote:

> I would have to say that if you 'started out with theintention of writing
> a corba front-and' then I dont think you can really speak for newbies.
> 
> When I started using postgresql I had vaguely heard of odbc and I had
> a couple of example queries of SQL.
> 
> If I had had to go to template1 and create database whatever; and THEN
> go use it, I would have been fairly confused.

Why?  How did you learn about the createdb or createuser commands in the
first place?  

Section 20 of the INSTALL file could read:

       20. Briefly test that the backend will start and 
           run by running it from the command line.
            a. Start the postmaster daemon running in the 
              background by typing 
              $ cd
              $ nohup postmaster -i > pgserver.log 2>&1 &
	    b. Connect to the database by typing
		$ psql template1
            b. Create a database by typing 
              $ create database testdb;
            c. Connect to the new database by typing:
              template1=> \connect testdb
            d. And run a sample query: 
              testdb=> SELECT datetime 'now';
            e. Exit psql: 
              testdb=> \q
            f. Remove the test database (unless you will 
              want to use it later for other tests): 
              testdb=> drop database testdb;

now the end user knows how to create and drop a database properly...

hell, add in a few extra steps for creating a new user and deleting
him...once ppl know the commands exist, they will use them and learn how
to better use them...

For 'newbies', they learn about createdb/createuser from the INSTALL
file...it doesn't take anything to teach them to do 'CREATE DATABASE' vs
'createdb', and it gives them the *proper* way to do it...

Marc G. Fournier                   ICQ#7615664               IRC Nick: Scrappy
Systems Administrator @ hub.org 
primary: scrappy@hub.org           secondary: scrappy@{freebsd|postgresql}.org

Re: [HACKERS] Re: HISTORY for 6.5.2

Vince Vielhaber <vev@michvhf.com> — 1999-09-21T01:52:29Z

On 21-Sep-99 The Hermit Hacker wrote:
> On Mon, 20 Sep 1999, Bruce Momjian wrote:
> 
>> > My personal dislike for them is that they are incomplete...CREATE USER and
>> > CREATE DATABASE  have a helluva lot of options available to it...using
>> > createuser, you don't know/learn abotu them...
>> > 
>> > Force the admin to learn what they are doing...if they want to create
>> > short cut scripts, let *them* do it...
>> 
>> But newbies can't do shortcuts.  I think we need to keep it.
> 
> Newbies can't read man pages to type 'CREATE USER <userid>' or 'CREATE
> DATABASE <database>'?

You're missing one minor point.  It's highly probable you never experienced
it.  The first few days (maybe even couple of weeks) PostgreSQL can be 
intimidating.  Most packages install the same way: 

./configure
make 
make install

and you can do it from whatever directory you want.  Right from the 
beginning, the postgres installation has you working from a directory
that you may not normally keep your sources in (I keep mine in /usr/local/src
as do many others), working as a user you just created so you're in an
unfamiliar environment.  Then the redirection of the make process (or the
gmake process) monitoring it with tail....  For the first time installer
it can be intimidating.   Hell, Innd 1.4 was easier to install the first 
time.  After doing it more than once (and using Tom's tip with makefile.custom)
all of that can be gotten around.   Then the regression tests.  Lets face
it, it's a big package - well worth the effort to learn it, but it's still
big.  So after putting the poor newbie thru all of this trauma you want to 
further traumatize him/her with man pages?    :)

> We're not asking anyone to learn rocket science here...we leave that to
> Thomas :)

Good candidate too :)

Vince.
-- 
==========================================================================
Vince Vielhaber -- KA8CSH   email: vev@michvhf.com   flame-mail: /dev/null
       # include <std/disclaimers.h>                   TEAM-OS2
        Online Campground Directory    http://www.camping-usa.com
       Online Giftshop Superstore    http://www.cloudninegifts.com
==========================================================================

Re: [HACKERS] Re: HISTORY for 6.5.2

Vince Vielhaber <vev@michvhf.com> — 1999-09-21T01:55:16Z

On 21-Sep-99 The Hermit Hacker wrote:
> On Tue, 21 Sep 1999, Michael Simms wrote:
> 
>> I would have to say that if you 'started out with theintention of writing
>> a corba front-and' then I dont think you can really speak for newbies.
>> 
>> When I started using postgresql I had vaguely heard of odbc and I had
>> a couple of example queries of SQL.
>> 
>> If I had had to go to template1 and create database whatever; and THEN
>> go use it, I would have been fairly confused.
> 
> Why?  How did you learn about the createdb or createuser commands in the
> first place?  
> 
> Section 20 of the INSTALL file could read:
> 
>        20. Briefly test that the backend will start and 
>            run by running it from the command line.
>             a. Start the postmaster daemon running in the 
>               background by typing 
>               $ cd
>               $ nohup postmaster -i > pgserver.log 2>&1 &
>           b. Connect to the database by typing
>               $ psql template1
>             b. Create a database by typing 
>               $ create database testdb;
>             c. Connect to the new database by typing:
>               template1=> \connect testdb
>             d. And run a sample query: 
>               testdb=> SELECT datetime 'now';
>             e. Exit psql: 
>               testdb=> \q
>             f. Remove the test database (unless you will 
>               want to use it later for other tests): 
>               testdb=> drop database testdb;

e and f mixed up?

Vince.
-- 
==========================================================================
Vince Vielhaber -- KA8CSH   email: vev@michvhf.com   flame-mail: /dev/null
       # include <std/disclaimers.h>                   TEAM-OS2
        Online Campground Directory    http://www.camping-usa.com
       Online Giftshop Superstore    http://www.cloudninegifts.com
==========================================================================

Re: [HACKERS] Re: HISTORY for 6.5.2

Bruce Momjian <maillist@candle.pha.pa.us> — 1999-09-21T01:55:17Z

> > But newbies can't do shortcuts.  I think we need to keep it.
> 
> Newbies can't read man pages to type 'CREATE USER <userid>' or 'CREATE
> DATABASE <database>'?
> 
> We're not asking anyone to learn rocket science here...we leave that to
> Thomas :)

But we have to get the newbie started before they are going to dive in
and learn manuals.

I don't read the manuals until I decide I want to use some new piece of
software.  I am reading the LyX manuals now only after using it for a
few weeks and deciding I want to move from troff to lyx.

Because it is part of getting started, it has to be easy.

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

Re: [HACKERS] Re: HISTORY for 6.5.2

Marc G. Fournier <scrappy@hub.org> — 1999-09-21T02:10:58Z

On Mon, 20 Sep 1999, Vince Vielhaber wrote:

> 
> On 21-Sep-99 The Hermit Hacker wrote:
> > On Tue, 21 Sep 1999, Michael Simms wrote:
> > 
> >> I would have to say that if you 'started out with theintention of writing
> >> a corba front-and' then I dont think you can really speak for newbies.
> >> 
> >> When I started using postgresql I had vaguely heard of odbc and I had
> >> a couple of example queries of SQL.
> >> 
> >> If I had had to go to template1 and create database whatever; and THEN
> >> go use it, I would have been fairly confused.
> > 
> > Why?  How did you learn about the createdb or createuser commands in the
> > first place?  
> > 
> > Section 20 of the INSTALL file could read:
> > 
> >        20. Briefly test that the backend will start and 
> >            run by running it from the command line.
> >             a. Start the postmaster daemon running in the 
> >               background by typing 
> >               $ cd
> >               $ nohup postmaster -i > pgserver.log 2>&1 &
> >           b. Connect to the database by typing
> >               $ psql template1
> >             b. Create a database by typing 
> >               $ create database testdb;
> >             c. Connect to the new database by typing:
> >               template1=> \connect testdb
> >             d. And run a sample query: 
> >               testdb=> SELECT datetime 'now';
> >             e. Exit psql: 
> >               testdb=> \q
> >             f. Remove the test database (unless you will 
> >               want to use it later for other tests): 
> >               testdb=> drop database testdb;
> 
> e and f mixed up?

*glare*  it was a sample...:P

Marc G. Fournier                   ICQ#7615664               IRC Nick: Scrappy
Systems Administrator @ hub.org 
primary: scrappy@hub.org           secondary: scrappy@{freebsd|postgresql}.org

Re: [HACKERS] Re: HISTORY for 6.5.2

Marc G. Fournier <scrappy@hub.org> — 1999-09-21T02:13:07Z

On Mon, 20 Sep 1999, Bruce Momjian wrote:

> > > But newbies can't do shortcuts.  I think we need to keep it.
> > 
> > Newbies can't read man pages to type 'CREATE USER <userid>' or 'CREATE
> > DATABASE <database>'?
> > 
> > We're not asking anyone to learn rocket science here...we leave that to
> > Thomas :)
> 
> But we have to get the newbie started before they are going to dive in
> and learn manuals.

Section 20 of the INSTALL file *does that*...but get them started the
right way, using the proper commands is all I'm saying...

How else is someone going to know about {create,destroy}{user,db} in the
first place, but by reading through the INSTALL file...so change that so
that they learn to connect to the database and use proper SQL...

That is all my point is...we are already telling them how to get started,
let's change that to "how to get started the proper way"...

Marc G. Fournier                   ICQ#7615664               IRC Nick: Scrappy
Systems Administrator @ hub.org 
primary: scrappy@hub.org           secondary: scrappy@{freebsd|postgresql}.org

Re: [HACKERS] Re: HISTORY for 6.5.2

Bruce Momjian <maillist@candle.pha.pa.us> — 1999-09-21T02:47:38Z

> You're missing one minor point.  It's highly probable you never experienced
> it.  The first few days (maybe even couple of weeks) PostgreSQL can be 
> intimidating.  Most packages install the same way: 
> 
> ./configure
> make 
> make install
> 
> and you can do it from whatever directory you want.  Right from the 
> beginning, the postgres installation has you working from a directory
> that you may not normally keep your sources in (I keep mine in /usr/local/src
> as do many others), working as a user you just created so you're in an
> unfamiliar environment.  Then the redirection of the make process (or the
> gmake process) monitoring it with tail....  For the first time installer
> it can be intimidating.   Hell, Innd 1.4 was easier to install the first 
> time.  After doing it more than once (and using Tom's tip with makefile.custom)
> all of that can be gotten around.   Then the regression tests.  Lets face
> it, it's a big package - well worth the effort to learn it, but it's still
> big.  So after putting the poor newbie thru all of this trauma you want to 
> further traumatize him/her with man pages?    :)
> 

I agree our INSTALL is very large.  Is there some way we can simplify
the install process?

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

Re: [HACKERS] Re: HISTORY for 6.5.2

Thomas Lockhart <lockhart@alumni.caltech.edu> — 1999-09-21T05:59:54Z

> Force the admin to learn what they are doing...if they want to create
> short cut scripts, let *them* do it...

Damn. You're going to make me read the docs?

  - Thomas, who *always* uses the scripts and would miss them

-- 
Thomas Lockhart				lockhart@alumni.caltech.edu
South Pasadena, California

Re: [HACKERS] Re: HISTORY for 6.5.2

Marc G. Fournier <scrappy@hub.org> — 1999-09-21T06:14:40Z

On Tue, 21 Sep 1999, Thomas Lockhart wrote:

> > Force the admin to learn what they are doing...if they want to create
> > short cut scripts, let *them* do it...
> 
> Damn. You're going to make me read the docs?

IMHO...yes.  It would sure eliminate the "how do I change the password
for a user" if the person wanting to change that password had had to read
the docs in the first place, and witih know about the 'with password' part
of 'create user'...

...and, ummm...don't you have the docs memorized yet? :)

Marc G. Fournier                   ICQ#7615664               IRC Nick: Scrappy
Systems Administrator @ hub.org 
primary: scrappy@hub.org           secondary: scrappy@{freebsd|postgresql}.org

Re: [HACKERS] Re: HISTORY for 6.5.2

Hannu Krosing <hannu@tm.ee> — 1999-09-21T06:50:59Z

The Hermit Hacker wrote:
> 
> On Tue, 21 Sep 1999, Thomas Lockhart wrote:
> 
> > > Force the admin to learn what they are doing...if they want to create
> > > short cut scripts, let *them* do it...
> >
> > Damn. You're going to make me read the docs?
> 
> IMHO...yes.  It would sure eliminate the "how do I change the password
> for a user" if the person wanting to change that password had had to read
> the docs in the first place, and witih know about the 'with password' part
> of 'create user'...

To achieve that, you can't just instruct a newbie in INSTALL.TXT to do

$ psql template1
$> create user alex

but instead

$ psql template1
$>\h create user

or even better

RTFM 

;)

------------
Hannu

Re: [HACKERS] Re: HISTORY for 6.5.2

Vince Vielhaber <vev@michvhf.com> — 1999-09-21T09:27:25Z

On Mon, 20 Sep 1999, Bruce Momjian wrote:

> > You're missing one minor point.  It's highly probable you never experienced
> > it.  The first few days (maybe even couple of weeks) PostgreSQL can be 
> > intimidating.  Most packages install the same way: 
> > 
> > ./configure
> > make 
> > make install
> > 
> > and you can do it from whatever directory you want.  Right from the 
> > beginning, the postgres installation has you working from a directory
> > that you may not normally keep your sources in (I keep mine in /usr/local/src
> > as do many others), working as a user you just created so you're in an
> > unfamiliar environment.  Then the redirection of the make process (or the
> > gmake process) monitoring it with tail....  For the first time installer
> > it can be intimidating.   Hell, Innd 1.4 was easier to install the first 
> > time.  After doing it more than once (and using Tom's tip with makefile.custom)
> > all of that can be gotten around.   Then the regression tests.  Lets face
> > it, it's a big package - well worth the effort to learn it, but it's still
> > big.  So after putting the poor newbie thru all of this trauma you want to 
> > further traumatize him/her with man pages?    :)
> > 
> 
> I agree our INSTALL is very large.  Is there some way we can simplify
> the install process?

Yeah, but let me test it first.  I have two to install this week so I 
make sure.

Vince.
-- 
==========================================================================
Vince Vielhaber -- KA8CSH   email: vev@michvhf.com   flame-mail: /dev/null
       # include <std/disclaimers.h>                   TEAM-OS2
        Online Campground Directory    http://www.camping-usa.com
       Online Giftshop Superstore    http://www.cloudninegifts.com
==========================================================================

Re: [HACKERS] Re: HISTORY for 6.5.2

Bruce Momjian <maillist@candle.pha.pa.us> — 1999-09-21T14:01:40Z

> > Force the admin to learn what they are doing...if they want to create
> > short cut scripts, let *them* do it...
> 
> Damn. You're going to make me read the docs?
> 
>   - Thomas, who *always* uses the scripts and would miss them
> 

I created a script for testing called newdb which:

	:
	destroydb "$@"
	createdb "$@"

Yes, I could do this in psql from template1, but why bother.

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

Re: [HACKERS] Re: HISTORY for 6.5.2

Bruce Momjian <maillist@candle.pha.pa.us> — 1999-09-21T14:02:27Z

> On Tue, 21 Sep 1999, Thomas Lockhart wrote:
> 
> > > Force the admin to learn what they are doing...if they want to create
> > > short cut scripts, let *them* do it...
> > 
> > Damn. You're going to make me read the docs?
> 
> IMHO...yes.  It would sure eliminate the "how do I change the password
> for a user" if the person wanting to change that password had had to read
> the docs in the first place, and witih know about the 'with password' part
> of 'create user'...
> 
> ...and, ummm...don't you have the docs memorized yet? :)


Can we add some output to the createdb command to remind people it can
be done inside psql?

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

Re: [HACKERS] Re: HISTORY for 6.5.2

Marc G. Fournier <scrappy@hub.org> — 1999-09-21T14:45:49Z

On Tue, 21 Sep 1999, Bruce Momjian wrote:

> > On Tue, 21 Sep 1999, Thomas Lockhart wrote:
> > 
> > > > Force the admin to learn what they are doing...if they want to create
> > > > short cut scripts, let *them* do it...
> > > 
> > > Damn. You're going to make me read the docs?
> > 
> > IMHO...yes.  It would sure eliminate the "how do I change the password
> > for a user" if the person wanting to change that password had had to read
> > the docs in the first place, and witih know about the 'with password' part
> > of 'create user'...
> > 
> > ...and, ummm...don't you have the docs memorized yet? :)
> 
> 
> Can we add some output to the createdb command to remind people it can
> be done inside psql?

How about something that outputs what its executing?  

running 'psql -e "create database <databasename" template1'  or something
like that?

Or have the createdb command run 'man createdb' *grin*

Marc G. Fournier                   ICQ#7615664               IRC Nick: Scrappy
Systems Administrator @ hub.org 
primary: scrappy@hub.org           secondary: scrappy@{freebsd|postgresql}.org

Re: [HACKERS] Re: HISTORY for 6.5.2]

Bruce Momjian <maillist@candle.pha.pa.us> — 1999-09-21T14:52:16Z

> > Can we add some output to the createdb command to remind people it can
> > be done inside psql?
> 
> How about something that outputs what its executing?  
> 
> running 'psql -e "create database <databasename" template1'  or something
> like that?
> 
> Or have the createdb command run 'man createdb' *grin*

I was thinking:

	See the CREATE DATABASE command for more options.

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

Re: [HACKERS] Re: HISTORY for 6.5.2]

Thomas Lockhart <lockhart@alumni.caltech.edu> — 1999-09-21T15:21:31Z

> > Or have the createdb command run 'man createdb' *grin*
> I was thinking:
>         See the CREATE DATABASE command for more options.

I can't help thinking that this thread is trying to solve a problem
that isn't a problem. createdb works fine. You can do more from within
sql. So what? Someone could, if they thought it was a problem, add
more capabilities to createdb, and an admin could choose to use it or
not.

Seems to me that it works just fine for most cases right now; sure
does for me...

                      - Thomas

-- 
Thomas Lockhart				lockhart@alumni.caltech.edu
South Pasadena, California

Re: [HACKERS] Re: HISTORY for 6.5.2

Lamar Owen <lamar.owen@wgcr.org> — 1999-09-21T16:05:51Z

Vince Vielhaber wrote:
> it, it's a big package - well worth the effort to learn it, but it's still
> big.  So after putting the poor newbie thru all of this trauma you want to
> further traumatize him/her with man pages?    :)

You know, in two years I gotten quite cozy with PostgreSQL -- but at the
beginning it was not so.  I remember how it felt to FIRST install -- it
WAS intimidating.

Let's just take a look at HOW big postgresql has become: the tarball is
over six megabytes.  It decompresses to around 23 megabytes.  That is
half the size of the Linux Kernel sources, twice the size of a minimal
Windows 95 installation, and three times the size of a complete Windows
3.1 installation.

My first hard drive on my ancient TRS-80 model 4 was 10 megabytes, and
it seemed huge.  The PostgreSQL source tree is two times larger than the
maximum volume size for that OS!  In fact, a source tree that has
completed a make is bigger than the largest volume size for MS-DOS
versions prior to 4.0!

It has a ways to go to beat the 260+MB Oracle 8i installation package,
but it's still a big package.

It takes my Pentium 133 laptop running RedHat 6.0 a full 45 minutes to
build an RPM set -- that's a ./configure; make; make install sequence
with several other operations added on.  A machine that can do over 100
MIPS takes 45 minutes.  Think about it.

I have to say that I agree with Marc on this one, and, Vince, you are
the one who convinced me.

If a newbie (to PostgreSQL) can successfully install from source, then
said newbie won't have a single problem reading a man page.  Even with
the RPM packaging -- if a newbie can find out that you need to su to
postgres and run psql to get at the data (or set up some other client),
then said newbie really doesn't care whether the create db is a script
executed from the unix shell or an SQL command executed from psql. 
Whether it's a shell script or a psql command is irrelevant -- the
newbie is having to learn a new command either way.

IMHO

Lamar Owen
WGCR Internet Radio
1 Peter 4:11

Re: [HACKERS] Re: HISTORY for 6.5.2

Lamar Owen <lamar.owen@wgcr.org> — 1999-09-21T16:18:40Z

Bruce Momjian wrote:
> > big.  So after putting the poor newbie thru all of this trauma you want to
> > further traumatize him/her with man pages?    :)
> >
> 
> I agree our INSTALL is very large.  Is there some way we can simplify
> the install process?

rpm --install postgresql*.rpm (or dpkg postgresql*.deb)

;-P

(I just HAD to do that.....)  And, RPM will successfully install on more
than just RedHat Linux.  See www.rpm.org

Frankly, the installation (unless you are munging it into an
FHS-compliant package) is a piece of cake as it is (of course, I say
that with two years of PostgreSQL experience under my belt).  It
certainly is one of the easiest to install amongst packages of equal
size.

Most people who come to know PostgreSQL either:
1.)	Get it on their Linux CD;
2.)	Heard about it from their sysadmin friends;
3.)	Heard about it from someone who installed from a Linux CD;
4.)	Heard about it from the documentation of whatever application/web
server they're using.

In my case, it was number 4, as RedHat hadn't yet shipped it when I read
about it in the AOLserver documentation.

The only true "newbies" are in groups 1 and 3, as the others have some
experience with system administration.  And for those groups, it is
going in as an RPM or other package (such as Oliver's .deb).

Are there any OS's other than Linux where PostgreSQL is being shipped as
a stock part of the OS??  Given its BSD license, I would think the
*BSD's would be shipping it.

All we can really do is provide better and better documentation, which
has been getting MUCH better than the halcyon days of 6.1.1 (which was
my first version to install).

Lamar Owen
WGCR Internet Radio
1 Peter 4:11

Re: [HACKERS] Re: HISTORY for 6.5.2

Brook Milligan <brook@biology.nmsu.edu> — 1999-09-21T16:35:33Z

   Are there any OS's other than Linux where PostgreSQL is being shipped as
   a stock part of the OS??  Given its BSD license, I would think the
   *BSD's would be shipping it.

NetBSD includes postgresql as a component of the package system.

Cheers,
Brook

Re: [HACKERS] Re: HISTORY for 6.5.2

Vince Vielhaber <vev@michvhf.com> — 1999-09-21T16:44:58Z

On Tue, 21 Sep 1999, Brook Milligan wrote:

>    Are there any OS's other than Linux where PostgreSQL is being shipped as
>    a stock part of the OS??  Given its BSD license, I would think the
>    *BSD's would be shipping it.
> 
> NetBSD includes postgresql as a component of the package system.

Ditto FreeBSD.

Vince.
-- 
==========================================================================
Vince Vielhaber -- KA8CSH   email: vev@michvhf.com   flame-mail: /dev/null
       # include <std/disclaimers.h>                   TEAM-OS2
        Online Campground Directory    http://www.camping-usa.com
       Online Giftshop Superstore    http://www.cloudninegifts.com
==========================================================================

Re: [HACKERS] Re: HISTORY for 6.5.2

Lamar Owen <lamar.owen@wgcr.org> — 1999-09-21T17:14:50Z

Brook Milligan wrote:
> 
>    Are there any OS's other than Linux where PostgreSQL is being shipped as
>    a stock part of the OS??  Given its BSD license, I would think the
>    *BSD's would be shipping it.
> 
> NetBSD includes postgresql as a component of the package system.

Ah! Good.

Lamar Owen
WGCR Internet Radio
1 Peter 4:11

Re: [HACKERS] Re: HISTORY for 6.5.2]

Marc G. Fournier <scrappy@hub.org> — 1999-09-21T19:02:55Z

On Tue, 21 Sep 1999, Bruce Momjian wrote:

> > > Can we add some output to the createdb command to remind people it can
> > > be done inside psql?
> > 
> > How about something that outputs what its executing?  
> > 
> > running 'psql -e "create database <databasename" template1'  or something
> > like that?
> > 
> > Or have the createdb command run 'man createdb' *grin*
> 
> I was thinking:
> 
> 	See the CREATE DATABASE command for more options.

In bold, flashing letters? :)

Ya, that would be perfect...

Marc G. Fournier                   ICQ#7615664               IRC Nick: Scrappy
Systems Administrator @ hub.org 
primary: scrappy@hub.org           secondary: scrappy@{freebsd|postgresql}.org

Re: [HACKERS] Re: HISTORY for 6.5.2

Marc G. Fournier <scrappy@hub.org> — 1999-09-21T19:19:44Z

On Tue, 21 Sep 1999, Brook Milligan wrote:

>    Are there any OS's other than Linux where PostgreSQL is being shipped as
>    a stock part of the OS??  Given its BSD license, I would think the
>    *BSD's would be shipping it.
> 
> NetBSD includes postgresql as a component of the package system.

FreeBSD as both ports/package...but not part of standard install...we
don't really use it for anything as part of the OS...

Marc G. Fournier                   ICQ#7615664               IRC Nick: Scrappy
Systems Administrator @ hub.org 
primary: scrappy@hub.org           secondary: scrappy@{freebsd|postgresql}.org

Re: [HACKERS] Re: HISTORY for 6.5.2

Bruce Momjian <maillist@candle.pha.pa.us> — 1999-09-21T19:26:08Z

>    Are there any OS's other than Linux where PostgreSQL is being shipped as
>    a stock part of the OS??  Given its BSD license, I would think the
>    *BSD's would be shipping it.
> 
> NetBSD includes postgresql as a component of the package system.

BSDI is considering it.

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

INSTALL file (was Re: [HACKERS] Re: HISTORY for 6.5.2)

Peter Eisentraut <peter_e@gmx.net> — 1999-09-21T21:46:19Z

On Sep 20, Bruce Momjian mentioned:

> I agree our INSTALL is very large.  Is there some way we can simplify
> the install process?

On the one hand a database server is probably not your everyday
./configure && make && make install program you get from freshmeat and you
do want to put some time into a proper installation. On the other hand the
INSTALL file is really way too long and makes for unpleasant reading.

Here are a couple of ideas.

* Chapter 2 "Ports" should be moved to the README file (has nothing to do
with the actual installation).

* Move the gory details of item 5 (flex) to a separate file (README.flex).

* Move the locale stuff into a separate file.

* Same with Kerberos

* Move the release notes at the end to CHANGELOG.

That should make the file somewhat smaller, then also it is really to
verbose at times and is formatted really oddly, at least on my system.

Okay, now I really went out of my way and redid the whole thing. You'll
find the result attached. This is merely an idea of what I would consider
simpler. I removed some inconsistencies, things that were unnecessary, too
complicated, etc. Okay, I removed a lot of stuff, but most of the stuff
people can really figure out themselves if they need them in the first
place. And I shrunk the thing to 25%.

Perhaps there should be a separate Install FAQ of the sort "My shell said
'export: Command not found.'" or "What's a shared library?" to move the
really annoying stuff out of people's ways.

Comments?

-- 
Peter Eisentraut - peter_e@gmx.net
http://yi.org/peter-e

RE: INSTALL file (was Re: [HACKERS] Re: HISTORY for 6.5.2)

Vince Vielhaber <vev@michvhf.com> — 1999-09-21T21:59:07Z

On 21-Sep-99 Peter Eisentraut wrote:
> On Sep 20, Bruce Momjian mentioned:
> 
>> I agree our INSTALL is very large.  Is there some way we can simplify
>> the install process?
> 
> On the one hand a database server is probably not your everyday
> ./configure && make && make install program you get from freshmeat and you
> do want to put some time into a proper installation. 

I disagree.  When you remove the 'change to this user, install from this
directory' stuff and get down to the actual install, it is just as simple
as ./configure && make && make install.   That's how I've done it the last
few times.   And each time I've enabled different features.

Vince.
-- 
==========================================================================
Vince Vielhaber -- KA8CSH   email: vev@michvhf.com   flame-mail: /dev/null
       # include <std/disclaimers.h>                   TEAM-OS2
        Online Campground Directory    http://www.camping-usa.com
       Online Giftshop Superstore    http://www.cloudninegifts.com
==========================================================================

Re: [DOCS] INSTALL file (was Re: [HACKERS] Re: HISTORY for 6.5.2)

Thomas Lockhart <lockhart@alumni.caltech.edu> — 1999-09-22T15:48:29Z

> > I agree our INSTALL is very large.  Is there some way we can simplify
> > the install process?
> On the one hand a database server is probably not your everyday
> ./configure && make && make install program you get from freshmeat and you
> do want to put some time into a proper installation. On the other hand the
> INSTALL file is really way too long and makes for unpleasant reading.
> Here are a couple of ideas.
> That should make the file somewhat smaller, then also it is really to
> verbose at times and is formatted really oddly, at least on my system.

Formatted oddly, eh? ;)

We actually generate this file from files in doc/src/sgml/. We
generate RTF from the sgml sources, and then format to ascii text
using ApplixWare or <insert your favorite word processor here>. The
formatting options at that point are fairly limited afaik.

> Okay, now I really went out of my way and redid the whole thing. You'll
> find the result attached. This is merely an idea of what I would consider
> simpler. I removed some inconsistencies, things that were unnecessary, too
> complicated, etc. Okay, I removed a lot of stuff, but most of the stuff
> people can really figure out themselves if they need them in the first
> place. And I shrunk the thing to 25%.

Sounds great, except for the "people can figure it out for themselves"
part. But as long as the info is available somewhere in the docs, and
as long as people can get to them somehow if they need, then there is
probably no need for them to be in the INSTALL file.

> Perhaps there should be a separate Install FAQ of the sort "My shell said
> 'export: Command not found.'" or "What's a shared library?" to move the
> really annoying stuff out of people's ways.

And afaik once people have gotten to that point, the *real* docs will
have already been installed, so we can have that info there. I haven't
had a chance to look at your specific suggestions/changes, but I'm
sure they are a step forward.

                     - Thomas

-- 
Thomas Lockhart				lockhart@alumni.caltech.edu
South Pasadena, California

Re: [DOCS] INSTALL file (was Re: [HACKERS] Re: HISTORY for 6.5.2)

Bruce Momjian <maillist@candle.pha.pa.us> — 1999-09-22T16:45:49Z

> > > I agree our INSTALL is very large.  Is there some way we can simplify
> > > the install process?
> > On the one hand a database server is probably not your everyday
> > ./configure && make && make install program you get from freshmeat and you
> > do want to put some time into a proper installation. On the other hand the
> > INSTALL file is really way too long and makes for unpleasant reading.
> > Here are a couple of ideas.
> > That should make the file somewhat smaller, then also it is really to
> > verbose at times and is formatted really oddly, at least on my system.
> 
> Formatted oddly, eh? ;)
> 
> We actually generate this file from files in doc/src/sgml/. We
> generate RTF from the sgml sources, and then format to ascii text
> using ApplixWare or <insert your favorite word processor here>. The
> formatting options at that point are fairly limited afaik.

My recommendation is to output HTML, and use lynx to output ASCII.  I use:

	lynx -force_html -dump -hiddenlinks=ignore -nolist "$@"

You would be surprised how much better it looks, assuming the HTML is
good.

> > Okay, now I really went out of my way and redid the whole thing. You'll
> > find the result attached. This is merely an idea of what I would consider
> > simpler. I removed some inconsistencies, things that were unnecessary, too
> > complicated, etc. Okay, I removed a lot of stuff, but most of the stuff
> > people can really figure out themselves if they need them in the first
> > place. And I shrunk the thing to 25%.
> 
> Sounds great, except for the "people can figure it out for themselves"
> part. But as long as the info is available somewhere in the docs, and
> as long as people can get to them somehow if they need, then there is
> probably no need for them to be in the INSTALL file.
> 

Our big problem with the ASCII file is that we can't nest text, like we
can in HTML.  In HTML, we can say "Do this, and if it doesn't work,
click HERE", and have a page to describe known problems.   This allows
us to be brief, but give additional detail.  Footnotes in a book have a
similar purpose.  Maybe we can implement footnotes in the ASCII file. 
That is how I would do it in LyX.

> > Perhaps there should be a separate Install FAQ of the sort "My shell said
> > 'export: Command not found.'" or "What's a shared library?" to move the
> > really annoying stuff out of people's ways.
> 
> And afaik once people have gotten to that point, the *real* docs will
> have already been installed, so we can have that info there. I haven't
> had a chance to look at your specific suggestions/changes, but I'm
> sure they are a step forward.

Interesting idea, but you would have to point them to the exact spot. 
That may be tough.

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

Re: INSTALL file (was Re: [HACKERS] Re: HISTORY for 6.5.2)

Bruce Momjian <maillist@candle.pha.pa.us> — 1999-09-28T04:44:07Z

Thomas, can you comment on this.  I think he has a good point.  Can we
move some of the stuff to footnotes at the end of the file?  Can you try
converting to HTML first, then to text to see if it formats better:

	lynx -force_html -dump -hiddenlinks=ignore -nolist "$@"


> On Sep 20, Bruce Momjian mentioned:
> 
> > I agree our INSTALL is very large.  Is there some way we can simplify
> > the install process?
> 
> On the one hand a database server is probably not your everyday
> ./configure && make && make install program you get from freshmeat and you
> do want to put some time into a proper installation. On the other hand the
> INSTALL file is really way too long and makes for unpleasant reading.
> 
> Here are a couple of ideas.
> 
> * Chapter 2 "Ports" should be moved to the README file (has nothing to do
> with the actual installation).
> 
> * Move the gory details of item 5 (flex) to a separate file (README.flex).
> 
> * Move the locale stuff into a separate file.
> 
> * Same with Kerberos
> 
> * Move the release notes at the end to CHANGELOG.
> 
> That should make the file somewhat smaller, then also it is really to
> verbose at times and is formatted really oddly, at least on my system.
> 
> Okay, now I really went out of my way and redid the whole thing. You'll
> find the result attached. This is merely an idea of what I would consider
> simpler. I removed some inconsistencies, things that were unnecessary, too
> complicated, etc. Okay, I removed a lot of stuff, but most of the stuff
> people can really figure out themselves if they need them in the first
> place. And I shrunk the thing to 25%.
> 
> Perhaps there should be a separate Install FAQ of the sort "My shell said
> 'export: Command not found.'" or "What's a shared library?" to move the
> really annoying stuff out of people's ways.
> 
> Comments?
> 
> -- 
> Peter Eisentraut - peter_e@gmx.net
> http://yi.org/peter-e
Content-Description: New INSTALL file?

[Attachment, skipping...]


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

Re: INSTALL file (was Re: [HACKERS] Re: HISTORY for 6.5.2)

Bruce Momjian <pgman@candle.pha.pa.us> — 1999-11-29T23:16:33Z

I hope we can get everyone with ideas together before 7.0 is released.


> On Sep 20, Bruce Momjian mentioned:
> 
> > I agree our INSTALL is very large.  Is there some way we can simplify
> > the install process?
> 
> On the one hand a database server is probably not your everyday
> ./configure && make && make install program you get from freshmeat and you
> do want to put some time into a proper installation. On the other hand the
> INSTALL file is really way too long and makes for unpleasant reading.
> 
> Here are a couple of ideas.
> 
> * Chapter 2 "Ports" should be moved to the README file (has nothing to do
> with the actual installation).
> 
> * Move the gory details of item 5 (flex) to a separate file (README.flex).
> 
> * Move the locale stuff into a separate file.
> 
> * Same with Kerberos
> 
> * Move the release notes at the end to CHANGELOG.
> 
> That should make the file somewhat smaller, then also it is really to
> verbose at times and is formatted really oddly, at least on my system.
> 
> Okay, now I really went out of my way and redid the whole thing. You'll
> find the result attached. This is merely an idea of what I would consider
> simpler. I removed some inconsistencies, things that were unnecessary, too
> complicated, etc. Okay, I removed a lot of stuff, but most of the stuff
> people can really figure out themselves if they need them in the first
> place. And I shrunk the thing to 25%.
> 
> Perhaps there should be a separate Install FAQ of the sort "My shell said
> 'export: Command not found.'" or "What's a shared library?" to move the
> really annoying stuff out of people's ways.
> 
> Comments?
> 
> -- 
> Peter Eisentraut - peter_e@gmx.net
> http://yi.org/peter-e
Content-Description: New INSTALL file?

[Attachment, skipping...]


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

Re: INSTALL file (was Re: [HACKERS] Re: HISTORY for 6.5.2)

Vince Vielhaber <vev@michvhf.com> — 1999-11-29T23:28:46Z

On 29-Nov-99 Bruce Momjian wrote:
> 
> I hope we can get everyone with ideas together before 7.0 is released.

It can be greatly simplified but will require changes to configure which
I don't think I can do.  I haven't really gotten to know autoconf yet and
I think Peter said he's tied up till after the first of the year but he
still wants to dig into it.  Is after the first too late?

Vince.


> 
> 
>> On Sep 20, Bruce Momjian mentioned:
>> 
>> > I agree our INSTALL is very large.  Is there some way we can simplify
>> > the install process?
>> 
>> On the one hand a database server is probably not your everyday
>> ./configure && make && make install program you get from freshmeat and you
>> do want to put some time into a proper installation. On the other hand the
>> INSTALL file is really way too long and makes for unpleasant reading.
>> 
>> Here are a couple of ideas.
>> 
>> * Chapter 2 "Ports" should be moved to the README file (has nothing to do
>> with the actual installation).
>> 
>> * Move the gory details of item 5 (flex) to a separate file (README.flex).
>> 
>> * Move the locale stuff into a separate file.
>> 
>> * Same with Kerberos
>> 
>> * Move the release notes at the end to CHANGELOG.
>> 
>> That should make the file somewhat smaller, then also it is really to
>> verbose at times and is formatted really oddly, at least on my system.
>> 
>> Okay, now I really went out of my way and redid the whole thing. You'll
>> find the result attached. This is merely an idea of what I would consider
>> simpler. I removed some inconsistencies, things that were unnecessary, too
>> complicated, etc. Okay, I removed a lot of stuff, but most of the stuff
>> people can really figure out themselves if they need them in the first
>> place. And I shrunk the thing to 25%.
>> 
>> Perhaps there should be a separate Install FAQ of the sort "My shell said
>> 'export: Command not found.'" or "What's a shared library?" to move the
>> really annoying stuff out of people's ways.
>> 
>> Comments?
>> 
>> -- 
>> Peter Eisentraut - peter_e@gmx.net
>> http://yi.org/peter-e
> Content-Description: New INSTALL file?
> 
> [Attachment, skipping...]
> 
> 
> -- 
>   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

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

Re: INSTALL file (was Re: [HACKERS] Re: HISTORY for 6.5.2)

Bruce Momjian <pgman@candle.pha.pa.us> — 1999-11-29T23:38:41Z

> 
> On 29-Nov-99 Bruce Momjian wrote:
> > 
> > I hope we can get everyone with ideas together before 7.0 is released.
> 
> It can be greatly simplified but will require changes to configure which
> I don't think I can do.  I haven't really gotten to know autoconf yet and
> I think Peter said he's tied up till after the first of the year but he
> still wants to dig into it.  Is after the first too late?

No, I don't think so.

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