Thread: Re: [HACKERS] Re: HISTORY for 6.5.2
On Tue, 14 Sep 1999, Ryan Kirkpatrick wrote: > Yea, I am still around, though a bit busy with school at the > moment. I should be able to get 6.5.2beta downloaded and the alpha patches > updated for it by Monday if you want me to try. Or, if you get an updated > alpha patch before then, email it to me, and I will try it out. TTYL. You know that code far better than I; if you have time, applying those patches to the final 6.5.2 would be a nice thing. I'm applying my time to getting RPM upgrading working -- many thanks to Oliver Elphick for the Debian upgrade scripts, some of which are very useful even in an RPM context. Those 6.5.1 patches made alot of people very happy -- the guys at RedHat in particular. Bravo to Uncle George for them originally, and bravo to you for the backpatch and packaging to 6.5.1! Those patches, incidentally, will ship with RedHat 6.1, if nothing happens between now and release time. TIA! Lamar Owen WGCR Internet Radio
On Tue, 14 Sep 1999, Lamar Owen wrote: > On Tue, 14 Sep 1999, Ryan Kirkpatrick wrote: > > Yea, I am still around, though a bit busy with school at the > > moment. I should be able to get 6.5.2beta downloaded and the alpha patches > > updated for it by Monday if you want me to try. Or, if you get an updated > > alpha patch before then, email it to me, and I will try it out. TTYL. > > You know that code far better than I; if you have time, applying those patches > to the final 6.5.2 would be a nice thing. I'm applying my time to getting RPM > upgrading working -- many thanks to Oliver Elphick for the Debian upgrade > scripts, some of which are very useful even in an RPM context. Ok, I will do so this weekend, providing there are not too many things broken. I will let you know on Monday what the status is. :) Though, is the 6.5.2beta tar ball on the ftp site the one I want to work with, or do I want to go from something from CVS? And if so, what is the relevant tag? > Those 6.5.1 patches made alot of people very happy -- the guys at RedHat in > particular. Bravo to Uncle George for them originally, and bravo to you for > the backpatch and packaging to 6.5.1! Those patches, incidentally, will ship > with RedHat 6.1, if nothing happens between now and release time. Good to hear, and you are welcome! Hopefully by 6.6 the patches will not be needed and Linux/Alpha will finally be a fully supported pgsql platform! PS. Now that I made people at RedHat happy, can I get some of thier stock? :) **Just kidding** --------------------------------------------------------------------------- | "For to me to live is Christ, and to die is gain." | | --- Philippians 1:21 (KJV) | --------------------------------------------------------------------------- | Ryan Kirkpatrick | Boulder, Colorado | http://www.rkirkpat.net/ | ---------------------------------------------------------------------------
Ryan Kirkpatrick wrote: > Ok, I will do so this weekend, providing there are not too many > things broken. I will let you know on Monday what the status is. :) The current tarball is 6.5.2RC (for Release Candidate). AFAIK, this will become the release of 6.5.2, unless there are problems. Thanks much! > Good to hear, and you are welcome! Hopefully by 6.6 the patches > will not be needed and Linux/Alpha will finally be a fully supported pgsql > platform! Yes! Now if I just HAD one.... ;-) > PS. Now that I made people at RedHat happy, can I get some of > thier stock? :) **Just kidding** ROTFL.... I _wish_... Lamar Owen WGCR Internet Radio 1 Peter 4:11
Lamar Owen wrote: > > Ryan Kirkpatrick wrote: > > Ok, I will do so this weekend, providing there are not too many > > things broken. I will let you know on Monday what the status is. :) > > The current tarball is 6.5.2RC (for Release Candidate). AFAIK, this > will become the release of 6.5.2, unless there are problems. > > Thanks much! > > > Good to hear, and you are welcome! Hopefully by 6.6 the patches > > will not be needed and Linux/Alpha will finally be a fully supported pgsql > > platform! > > Yes! Now if I just HAD one.... ;-) Dont know if it's been raised before, but the postgres utilities are installed into /usr/bin from the rpm. Problem with this is the naming of some of the utilities eg.createuser, destroyuser. These could be confused with the 'standard' user utilities such as useradd, userdel etc. How about pre-pending a 'pg' to all postgres utilities so that these become pgcreateuser, pgdestroyuser etc.? -------- Regards Theo
On Thu, 16 Sep 1999, Lamar Owen wrote: > Ryan Kirkpatrick wrote: > > Ok, I will do so this weekend, providing there are not too many > > things broken. I will let you know on Monday what the status is. :) > > The current tarball is 6.5.2RC (for Release Candidate). AFAIK, this > will become the release of 6.5.2, unless there are problems. Ok, I grabbed 6.5.2, and after only minor trouble, have an alpha-patched version. The biggest changes to the patch was that a few of the "safe" changes made by the 6.5.1 alpha patches have made thier way into the source tree (i.e. CPU defintions in the configure and makefiles). Only one instance where changes in actual source code broke and patch, and that instance was trival.I am running regression tests on the 6.5.2 alpha patched binaries now. Once they pass, I will post the patch to the list. > > Good to hear, and you are welcome! Hopefully by 6.6 the patches > > will not be needed and Linux/Alpha will finally be a fully supported pgsql > > platform! > > Yes! Now if I just HAD one.... ;-) They are nice machines... And there is a nice range of price/perf on them, everything from low end inexpensive machine to top of the end bank-busting machines. :) If you are really interested in playing around with an Alpha, I would recommend something like an AS200 at the low end, or a PC164LX at the mid end. Don't waste your time on a UDB though, they are more trouble then they are worth (overheat and die after a few years :( ). --------------------------------------------------------------------------- | "For to me to live is Christ, and to die is gain." | | --- Philippians 1:21 (KJV) | --------------------------------------------------------------------------- | Ryan Kirkpatrick | Boulder, Colorado | http://www.rkirkpat.net/ | ---------------------------------------------------------------------------
On Fri, 17 Sep 1999, Theo Kramer wrote: > Dont know if it's been raised before, but the postgres utilities are installed > into /usr/bin from the rpm. Problem with this is the naming of some of the > utilities eg.createuser, destroyuser. These could be confused with the > 'standard' user utilities such as useradd, userdel etc. How about pre-pending > a 'pg' to all postgres utilities so that these become pgcreateuser, > pgdestroyuser etc.? This is an interesting idea. What is also interesting is that if you have a traditional postgresql installation (/usr/local/pgsql), you can get even wierder results if /usr/bin contains one createuser and /usr/local/pgsql/bin contains another. Depending upon your PATH, you could get unwanted results in a hurry. 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.). Thoughts?? Lamar Owen WGCR Internet Radio
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
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
> 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, Pennsylvania19026
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.
> > 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
> > 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
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
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
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 ...
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
IIRC majordomo puts the whole slew of commands in the same directory, usually /usr/local/bin when you install it. Mostof 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
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
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
==========================================================================
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
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...
> 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, Pennsylvania19026
> 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
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
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.
Startthe 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
databaseby 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
itlater 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
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
==========================================================================
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
==========================================================================
> > 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, Pennsylvania19026
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
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
> 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, Pennsylvania19026
> 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
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
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
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
==========================================================================
> > 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, Pennsylvania19026
> 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, Pennsylvania19026
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
> > 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, Pennsylvania19026
> > 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
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
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
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
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
==========================================================================
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
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
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
> 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, Pennsylvania19026