Do people want pgaccess updated to 0.98 for the 6.5.2 release?

-- 
  Bruce Momjian                        |  http://www.op.net/~candle
  maillist@candle.pha.pa.us            |  (610) 853-3000
  +  If your life is a hard drive,     |  830 Blythe Avenue
  +  Christ can be your backup.        |  Drexel Hill, Pennsylvania 19026

Sun, 12 Sep 1999 20:28:51 -0400 (EDT)
Bruce Momjian <maillist@candle.pha.pa.us>
pgaccess update for 6.5.2?
Bruce Momjian wrote:
> 
> Do people want pgaccess updated to 0.98 for the 6.5.2 release?

It would be just fine.
I'm waiting for a german translation this week and everything seems to
be ok. No bugs have been discovered.
When should be the package prepared to be inserted into 6.5.2 ?

-- 
Constantin Teodorescu
FLEX Consulting Braila, ROMANIA

Mon, 13 Sep 1999 06:16:40 +0000
Constantin Teodorescu <teo@flex.ro>
Re: pgaccess update for 6.5.2?
On Mon, 13 Sep 1999, Constantin Teodorescu wrote:

> Bruce Momjian wrote:
> > 
> > Do people want pgaccess updated to 0.98 for the 6.5.2 release?
> 
> It would be just fine.
> I'm waiting for a german translation this week and everything seems to
> be ok. No bugs have been discovered.
> When should be the package prepared to be inserted into 6.5.2 ?

Am going to do a roll-out on Tuesday evenin...

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


Mon, 13 Sep 1999 11:05:25 -0300 (ADT)
The Hermit Hacker <scrappy@hub.org>
Re: [HACKERS] Re: pgaccess update for 6.5.2?
> Bruce Momjian wrote:
> > 
> > Do people want pgaccess updated to 0.98 for the 6.5.2 release?
> 
> It would be just fine.
> I'm waiting for a german translation this week and everything seems to
> be ok. No bugs have been discovered.
> When should be the package prepared to be inserted into 6.5.2 ?

The real issue was not if it was stable, but whether a non-bugfix
release of pgaccess was proper for a 6.5.2 release.  I haven't heard any
comments on that yet.  Not sure how I feel either.

-- 
  Bruce Momjian                        |  http://www.op.net/~candle
  maillist@candle.pha.pa.us            |  (610) 853-3000
  +  If your life is a hard drive,     |  830 Blythe Avenue
  +  Christ can be your backup.        |  Drexel Hill, Pennsylvania 19026

Mon, 13 Sep 1999 10:36:28 -0400 (EDT)
Bruce Momjian <maillist@candle.pha.pa.us>
Re: [HACKERS] Re: pgaccess update for 6.5.2?
> On Mon, 13 Sep 1999, Constantin Teodorescu wrote:
> 
> > Bruce Momjian wrote:
> > > 
> > > Do people want pgaccess updated to 0.98 for the 6.5.2 release?
> > 
> > It would be just fine.
> > I'm waiting for a german translation this week and everything seems to
> > be ok. No bugs have been discovered.
> > When should be the package prepared to be inserted into 6.5.2 ?
> 
> Am going to do a roll-out on Tuesday evenin...

I will take this as a "Yes", you want the new pgaccess.  Adding it now.

-- 
  Bruce Momjian                        |  http://www.op.net/~candle
  maillist@candle.pha.pa.us            |  (610) 853-3000
  +  If your life is a hard drive,     |  830 Blythe Avenue
  +  Christ can be your backup.        |  Drexel Hill, Pennsylvania 19026

Mon, 13 Sep 1999 10:38:02 -0400 (EDT)
Bruce Momjian <maillist@candle.pha.pa.us>
Re: [HACKERS] Re: pgaccess update for 6.5.2?
Bruce Momjian wrote:
> 
> The real issue was not if it was stable, but whether a non-bugfix
> release of pgaccess was proper for a 6.5.2 release.  I haven't heard any
> comments on that yet.  Not sure how I feel either.

It's rock solid stable.

I am using it for 2 weeks and just minor bugs have been reported (some
color problems on Solaris that have been fixed, some messages missing
from translations).

It will be ready for tomorow to be picked up and included in 6.5.2
distribution.
Just I will need a final confirmation with 10 minutes before someone
downloads the .tar.gz to be sure that it will be the right one.
I'll be (I hope) reachable by e-mail checking my mailbox every 1 minute.

Please, there is available a bug fix list for 6.5.2 ?

Teo

Mon, 13 Sep 1999 14:51:16 +0000
Constantin Teodorescu <teo@flex.ro>
Re: [HACKERS] Re: pgaccess update for 6.5.2?
> Bruce Momjian wrote:
> > 
> > The real issue was not if it was stable, but whether a non-bugfix
> > release of pgaccess was proper for a 6.5.2 release.  I haven't heard any
> > comments on that yet.  Not sure how I feel either.
> 
> It's rock solid stable.
> 
> I am using it for 2 weeks and just minor bugs have been reported (some
> color problems on Solaris that have been fixed, some messages missing
> from translations).
> 
> It will be ready for tomorow to be picked up and included in 6.5.2
> distribution.
> Just I will need a final confirmation with 10 minutes before someone
> downloads the .tar.gz to be sure that it will be the right one.
> I'll be (I hope) reachable by e-mail checking my mailbox every 1 minute.
> 
> Please, there is available a bug fix list for 6.5.2 ?

Can I download it now?

-- 
  Bruce Momjian                        |  http://www.op.net/~candle
  maillist@candle.pha.pa.us            |  (610) 853-3000
  +  If your life is a hard drive,     |  830 Blythe Avenue
  +  Christ can be your backup.        |  Drexel Hill, Pennsylvania 19026

Mon, 13 Sep 1999 11:05:40 -0400 (EDT)
Bruce Momjian <maillist@candle.pha.pa.us>
Re: [HACKERS] Re: pgaccess update for 6.5.2?
Bruce,

in HISTORY for 6.5.2 I see:

This is to re-use space on index pages freed by vacuum(Tom)

isn't this re-use indices after vacuum hack by Vadim ?
(prevent indices to grow infinitely)

	Regards,

		Oleg

_____________________________________________________________
Oleg Bartunov, sci.researcher, hostmaster of AstroNet,
Sternberg Astronomical Institute, Moscow University (Russia)
Internet: oleg@sai.msu.su, http://www.sai.msu.su/~megera/
phone: +007(095)939-16-83, +007(095)939-23-83


Mon, 13 Sep 1999 20:38:30 +0400 (MSD)
Oleg Bartunov <oleg@sai.msu.su>
HISTORY for 6.5.2
> Bruce,
> 
> in HISTORY for 6.5.2 I see:
> 
> This is to re-use space on index pages freed by vacuum(Tom)
> 
> isn't this re-use indices after vacuum hack by Vadim ?
> (prevent indices to grow infinitely)
> 

Thanks.  I have updated the release.sgml and the HISTORY file.

I should have posted the list of changes.  Here it is.  Gee, it is quite
a lot.  Thomas, any way to get the dates from the release.sgml into the
HISTORY file and the html output?

---------------------------------------------------------------------------



Detailed Change List

       subselect+CASE fixes(Tom)
       Add SHLIB_LINK setting for solaris_i386 and solaris_sparc ports(Daren
       Sefcik)
       Fixes for CASE in WHERE join clauses(Tom)
       Fix BTScan abort(Tom)
       Repair the check for redundant UNIQUE and PRIMARY KEY indices(Tom)
       Improve it so that it checks for multi-column constraints(Tom)
       Fix for Win32 making problem with MB enabled(Hiroki Kataoka)
       Allow BSD yacc and bison to compile pl code(Bruce)
       Fix SET NAMES
       int8 fixes(Thomas)
       Fix vacuum's memory consumption(Tom)
       Reduce the total memory consumption of vacuum(Tom)
       Fix for timestamp(datetime)
       Rule deparsing bugfixes(Tom)
       Fix quoting problems in mkMakefile.tcldefs.sh.in and
       mkMakefile.tkdefs.sh.in(Tom)
       Update frontend libpq to remove limits on query lengths,
       error/notice message lengths, and number of fields per tuple(Tom)
       This is to re-use space on index pages freed by vacuum(Vadim)
       document -x for pg_dump(Bruce)
       Fix for unary operators in rule deparser(Tom)
       Comment out FileUnlink of excess segments during mdtruncate()(Tom)
       Irix linking fix from Yu Cao <yucao@falcon.kla-tencor.com>
       Repair logic error in LIKE: should not return LIKE_ABORT
       when reach end of pattern before end of text(Tom)
       Repair incorrect cleanup of heap memory allocation during transaction
       abort(Tom)

-- 
  Bruce Momjian                        |  http://www.op.net/~candle
  maillist@candle.pha.pa.us            |  (610) 853-3000
  +  If your life is a hard drive,     |  830 Blythe Avenue
  +  Christ can be your backup.        |  Drexel Hill, Pennsylvania 19026

Mon, 13 Sep 1999 13:11:11 -0400 (EDT)
Bruce Momjian <maillist@candle.pha.pa.us>
Re: HISTORY for 6.5.2
Oleg Bartunov <oleg@sai.msu.su> writes:
> in HISTORY for 6.5.2 I see:
> This is to re-use space on index pages freed by vacuum(Tom)
> isn't this re-use indices after vacuum hack by Vadim ?

Not mine, for sure.

			regards, tom lane

Mon, 13 Sep 1999 13:36:07 -0400
Tom Lane <tgl@sss.pgh.pa.us>
Re: [HACKERS] HISTORY for 6.5.2 
Bruce Momjian wrote:

---------------------------------------------------------------------------
> 
> Detailed Change List
> 
[snip]

Hey, Bruce -- did the patches for Alpha get in??  If not, I'll need to
mung Ryan K's/Uncle G's patchset against 6.5.1 to work with 6.5.2.

Your friendly RPM packager...

Lamar Owen
WGCR Internet Radio

Mon, 13 Sep 1999 13:42:16 -0400
Lamar Owen <lamar.owen@wgcr.org>
Re: [HACKERS] Re: HISTORY for 6.5.2
> Bruce Momjian wrote:
> 
> ---------------------------------------------------------------------------
> > 
> > Detailed Change List
> > 
> [snip]
> 
> Hey, Bruce -- did the patches for Alpha get in??  If not, I'll need to
> mung Ryan K's/Uncle G's patchset against 6.5.1 to work with 6.5.2.
> 
> Your friendly RPM packager...

The bad news is that those patches are too large/significant for a minor
release.  They could affect other platforms adversely, so we can't apply
them until 6.6.

-- 
  Bruce Momjian                        |  http://www.op.net/~candle
  maillist@candle.pha.pa.us            |  (610) 853-3000
  +  If your life is a hard drive,     |  830 Blythe Avenue
  +  Christ can be your backup.        |  Drexel Hill, Pennsylvania 19026

Mon, 13 Sep 1999 13:47:19 -0400 (EDT)
Bruce Momjian <maillist@candle.pha.pa.us>
Re: [HACKERS] Re: HISTORY for 6.5.2
Bruce Momjian wrote:
 
> The bad news is that those patches are too large/significant for a minor
> release.  They could affect other platforms adversely, so we can't apply
> them until 6.6.

Ok, mung time, then.  That means RedHat will be releasing 6.5.1 with
RedHat 6.1, unless those patches can be munged relatively easily. Alpha
is a big platform for RedHat.

Lamar Owen
WGCR Internet Radio

Mon, 13 Sep 1999 13:50:33 -0400
Lamar Owen <lamar.owen@wgcr.org>
Re: [HACKERS] Re: HISTORY for 6.5.2
> Bruce Momjian wrote:
>  
> > The bad news is that those patches are too large/significant for a minor
> > release.  They could affect other platforms adversely, so we can't apply
> > them until 6.6.
> 
> Ok, mung time, then.  That means RedHat will be releasing 6.5.1 with
> RedHat 6.1, unless those patches can be munged relatively easily. Alpha
> is a big platform for RedHat.
> 

It would be very valid to apply Uncle George's patches to a 6.5.2
alpha-only release.  If we had an alpha-only release, we would apply
them too.

Our problem is that minor releases don't get the same cross-platform
testing as major releases.

-- 
  Bruce Momjian                        |  http://www.op.net/~candle
  maillist@candle.pha.pa.us            |  (610) 853-3000
  +  If your life is a hard drive,     |  830 Blythe Avenue
  +  Christ can be your backup.        |  Drexel Hill, Pennsylvania 19026

Mon, 13 Sep 1999 13:55:09 -0400 (EDT)
Bruce Momjian <maillist@candle.pha.pa.us>
Re: [HACKERS] Re: HISTORY for 6.5.2
On Mon, 13 Sep 1999, Bruce Momjian wrote:

> > Ok, mung time, then.  That means RedHat will be releasing 6.5.1 with
> > RedHat 6.1, unless those patches can be munged relatively easily. Alpha
> > is a big platform for RedHat.
> > 
> 
> It would be very valid to apply Uncle George's patches to a 6.5.2
> alpha-only release.  If we had an alpha-only release, we would apply
> them too.

Oh, I understand.  Somehow or another I thought 6.5.2 had those patches
integrated.  My error.

> Our problem is that minor releases don't get the same cross-platform
> testing as major releases.

I understand -- I am patch-munging as I write this, after booting into RedHat 6
on my notebook.  If Ryan K is still around, he may find it easier going, as he
did the backpatch to 6.5.1.  There are a couple of failed hunks, and some
reverses.  We'll see how it goes.

Lamar Owen
WGCR Internet Radio

Mon, 13 Sep 1999 14:00:07 -0400
Lamar Owen <lamar.owen@wgcr.org>
Re: [HACKERS] Re: HISTORY for 6.5.2
Bruce Momjian <maillist@candle.pha.pa.us> writes:
>        Repair the check for redundant UNIQUE and PRIMARY KEY indices(Tom)
>        Improve it so that it checks for multi-column constraints(Tom)

Those were Thomas, I believe.

>        Fix vacuum's memory consumption(Tom)
>        Reduce the total memory consumption of vacuum(Tom)

And I can't take credit for that either --- Hiroshi and/or Tatsuo get
the credit, IIRC.  (BTW, did we patch those into 6.5.*, or only 6.6?)

>        Update frontend libpq to remove limits on query lengths,
>        error/notice message lengths, and number of fields per tuple(Tom)

This is *not* in 6.5.*, only 6.6.

			regards, tom lane

Mon, 13 Sep 1999 16:56:28 -0400
Tom Lane <tgl@sss.pgh.pa.us>
Re: [HACKERS] Re: HISTORY for 6.5.2 
Bruce Momjian <maillist@candle.pha.pa.us> writes:
>> Hey, Bruce -- did the patches for Alpha get in??  If not, I'll need to
>> mung Ryan K's/Uncle G's patchset against 6.5.1 to work with 6.5.2.

> The bad news is that those patches are too large/significant for a minor
> release.  They could affect other platforms adversely, so we can't apply
> them until 6.6.

Also, most of them were patches for the portability problems in our
function call interface.  I still have hopes of redesigning the fmgr
interface completely before 6.6 --- see my message in the hackers
archives for 6/14/99.  If we get that done then there'll be no need for
the associated patches.  (If we don't, we'd better apply the patches,
since Alpha is not the only platform where there are problems...)

			regards, tom lane

Mon, 13 Sep 1999 17:01:40 -0400
Tom Lane <tgl@sss.pgh.pa.us>
Re: [HACKERS] Re: HISTORY for 6.5.2 
> Bruce Momjian <maillist@candle.pha.pa.us> writes:
> >        Repair the check for redundant UNIQUE and PRIMARY KEY indices(Tom)
> >        Improve it so that it checks for multi-column constraints(Tom)
> 
> Those were Thomas, I believe.

Done.

> 
> >        Fix vacuum's memory consumption(Tom)
> >        Reduce the total memory consumption of vacuum(Tom)
> 
> And I can't take credit for that either --- Hiroshi and/or Tatsuo get
> the credit, IIRC.  (BTW, did we patch those into 6.5.*, or only 6.6?)

Ah, let's give them both credit.

> 
> >        Update frontend libpq to remove limits on query lengths,
> >        error/notice message lengths, and number of fields per tuple(Tom)
> 
> This is *not* in 6.5.*, only 6.6.

Sorry.  Shows up in the that tag log, so something must be in there.  I
don't make this stuff up.  :-)

Checking...

-- 
  Bruce Momjian                        |  http://www.op.net/~candle
  maillist@candle.pha.pa.us            |  (610) 853-3000
  +  If your life is a hard drive,     |  830 Blythe Avenue
  +  Christ can be your backup.        |  Drexel Hill, Pennsylvania 19026

Mon, 13 Sep 1999 18:38:18 -0400 (EDT)
Bruce Momjian <maillist@candle.pha.pa.us>
Re: [HACKERS] Re: HISTORY for 6.5.2
> And I can't take credit for that either --- Hiroshi and/or Tatsuo get
> the credit, IIRC.  (BTW, did we patch those into 6.5.*, or only 6.6?)
> 
> >        Update frontend libpq to remove limits on query lengths,
> >        error/notice message lengths, and number of fields per tuple(Tom)
> 
> This is *not* in 6.5.*, only 6.6.

I have:
	
	RCS file: /usr/local/cvsroot/pgsql/src/interfaces/libpq/pqexpbuffer.c,v
	Working file: src/interfaces/libpq/pqexpbuffer.c
	head: 1.1
	branch:
	locks: strict
	access list:
	symbolic names:
	keyword substitution: kv
	total revisions: 1;     selected revisions: 1
	description:
	----------------------------
	revision 1.1
	date: 1999/08/31 01:37:37;  author: tgl;  state: Exp;
	Update frontend libpq to remove limits on query lengths,
	error/notice message lengths, and number of fields per tuple.  Add
	pqexpbuffer.c/.h, a frontend version of backend's stringinfo module.
	This is first step in applying Mike Ansley's long-query patches,
	even though he didn't do any of these particular changes...

Seems addition of text files shows up in all branches, which I guess
makes sense.  No cause for alarm.

-- 
  Bruce Momjian                        |  http://www.op.net/~candle
  maillist@candle.pha.pa.us            |  (610) 853-3000
  +  If your life is a hard drive,     |  830 Blythe Avenue
  +  Christ can be your backup.        |  Drexel Hill, Pennsylvania 19026

Mon, 13 Sep 1999 21:03:04 -0400 (EDT)
Bruce Momjian <maillist@candle.pha.pa.us>
Re: [HACKERS] Re: HISTORY for 6.5.2
Bruce Momjian <maillist@candle.pha.pa.us> writes:
>> This is *not* in 6.5.*, only 6.6.

> I have:
> 	RCS file: /usr/local/cvsroot/pgsql/src/interfaces/libpq/pqexpbuffer.c,v
> 	Working file: src/interfaces/libpq/pqexpbuffer.c
> 	head: 1.1

> Seems addition of text files shows up in all branches, which I guess
> makes sense.  No cause for alarm.

I've noticed that cvs log seems a little bogus in its handling of
branches, even though cvs status and cvs update know perfectly well
what belongs to the local branch and what doesn't.  If you say
"cvs log" you get the "current" (tip revision's) log entries, even
if you are in a directory that's been checked out with a sticky
branch tag.  If you say "cvs log -rBRANCH" you get the branch's
log entries, but *only* those applied since the branch was split;
there doesn't seem to be any way to get the full history as seen
in this branch.  And, as above, it's quite confusing about files
that are not in the local branch at all.

Dunno if the cvs folk consider these behaviors bugs or features,
but they're definitely something to be wary of when working in
a branch...

			regards, tom lane

Tue, 14 Sep 1999 09:53:52 -0400
Tom Lane <tgl@sss.pgh.pa.us>
Re: [HACKERS] Re: HISTORY for 6.5.2 
On Mon, 13 Sep 1999, Lamar Owen wrote:

> > Our problem is that minor releases don't get the same cross-platform
> > testing as major releases.
> 
> I understand -- I am patch-munging as I write this, after booting into RedHat 6
> on my notebook.  If Ryan K is still around, he may find it easier going, as he
> did the backpatch to 6.5.1.  There are a couple of failed hunks, and some
> reverses.  We'll see how it goes.

	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.

---------------------------------------------------------------------------
|   "For to me to live is Christ, and to die is gain."                    |
|                                            --- Philippians 1:21 (KJV)   |
---------------------------------------------------------------------------
|   Ryan Kirkpatrick  |  Boulder, Colorado  |  http://www.rkirkpat.net/   |
---------------------------------------------------------------------------


Tue, 14 Sep 1999 16:44:30 -0500 (CDT)
Ryan Kirkpatrick <rkirkpat@rkirkpat.net>
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

Tue, 14 Sep 1999 18:11:58 -0400
Lamar Owen <lamar.owen@wgcr.org>
Re: [HACKERS] Re: HISTORY for 6.5.2
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/   |
---------------------------------------------------------------------------


Wed, 15 Sep 1999 18:49:16 -0500 (CDT)
Ryan Kirkpatrick <rkirkpat@nag.cs.colorado.edu>
Re: [HACKERS] Re: HISTORY for 6.5.2
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

Thu, 16 Sep 1999 15:37:37 -0400
Lamar Owen <lamar.owen@wgcr.org>
Re: [HACKERS] Re: HISTORY for 6.5.2
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

Fri, 17 Sep 1999 08:53:52 +0200
Theo Kramer <theo@flame.co.za>
Re: [HACKERS] Re: HISTORY for 6.5.2
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/   |
---------------------------------------------------------------------------


Sat, 18 Sep 1999 09:58:48 -0500 (CDT)
Ryan Kirkpatrick <rkirkpat@nag.cs.colorado.edu>
Re: [HACKERS] Re: HISTORY for 6.5.2
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

Sat, 18 Sep 1999 16:27:08 -0400
Lamar Owen <lamar.owen@wgcr.org>
Re: [HACKERS] Re: HISTORY for 6.5.2
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

Sat, 18 Sep 1999 17:00:41 -0400
Tom Lane <tgl@sss.pgh.pa.us>
Re: [HACKERS] Re: HISTORY for 6.5.2 
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

Sat, 18 Sep 1999 17:15:07 -0400
Lamar Owen <lamar.owen@wgcr.org>
Re: [HACKERS] Re: HISTORY for 6.5.2
> 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

Sat, 18 Sep 1999 17:38:16 -0400 (EDT)
Bruce Momjian <maillist@candle.pha.pa.us>
Re: [HACKERS] Re: HISTORY for 6.5.2
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.

18 Sep 1999 18:38:55 -0400
Michael Alan Dorman <mdorman@debian.org>
Re: [HACKERS] Re: HISTORY for 6.5.2
> > 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

Sun, 19 Sep 1999 05:51:22 +0000
Thomas Lockhart <lockhart@alumni.caltech.edu>
Re: [HACKERS] Re: HISTORY for 6.5.2
> > 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

Sun, 19 Sep 1999 07:14:57 +0100 (BST)
Michael Simms <grim@argh.demon.co.uk>
Re: [HACKERS] Re: HISTORY for 6.5.2
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

Sun, 19 Sep 1999 15:33:21 -0400
Lamar Owen <lamar.owen@wgcr.org>
Re: [HACKERS] Re: HISTORY for 6.5.2
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

Sun, 19 Sep 1999 16:13:28 -0400
frankpit@pop.dn.net
Re: [HACKERS] Re: HISTORY for 6.5.2

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

Mon, 20 Sep 1999 09:53:29 +0400 (MSD)
Dmitry Samersoff <dms@wplus.net>
Re: [HACKERS] Re: HISTORY for 6.5.2
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

Mon, 20 Sep 1999 09:28:40 +0200
Theo Kramer <theo@flame.co.za>
Re: [HACKERS] Re: HISTORY for 6.5.2
   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

Mon, 20 Sep 1999 10:19:49 -0600 (MDT)
Brook Milligan <brook@biology.nmsu.edu>
Re: [HACKERS] Re: HISTORY for 6.5.2
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 


Mon, 20 Sep 1999 18:36:32 -0300 (ADT)
The Hermit Hacker <scrappy@hub.org>
Re: [HACKERS] Re: HISTORY for 6.5.2

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



Mon, 20 Sep 1999 18:18:15 -0400 (EDT)
Vince Vielhaber <vev@michvhf.com>
Re: [HACKERS] Re: HISTORY for 6.5.2
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 


Mon, 20 Sep 1999 19:26:29 -0300 (ADT)
The Hermit Hacker <scrappy@hub.org>
Re: [HACKERS] Re: HISTORY for 6.5.2
> 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

Mon, 20 Sep 1999 18:46:33 -0400 (EDT)
Bruce Momjian <maillist@candle.pha.pa.us>
Re: [HACKERS] Re: HISTORY for 6.5.2

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


Mon, 20 Sep 1999 15:47:16 -0700 (PDT)
Yu Cao <yucao@falcon.kla-tencor.com>
Re: [HACKERS] Re: HISTORY for 6.5.2
> 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

Tue, 21 Sep 1999 00:20:21 +0100 (BST)
Michael Simms <grim@argh.demon.co.uk>
Re: [HACKERS] Re: HISTORY for 6.5.2
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 


Mon, 20 Sep 1999 22:26:42 -0300 (ADT)
The Hermit Hacker <scrappy@hub.org>
Re: [HACKERS] Re: HISTORY for 6.5.2
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 


Mon, 20 Sep 1999 22:44:04 -0300 (ADT)
The Hermit Hacker <scrappy@hub.org>
Re: [HACKERS] Re: HISTORY for 6.5.2

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



Mon, 20 Sep 1999 21:52:29 -0400 (EDT)
Vince Vielhaber <vev@michvhf.com>
Re: [HACKERS] Re: HISTORY for 6.5.2

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



Mon, 20 Sep 1999 21:55:16 -0400 (EDT)
Vince Vielhaber <vev@michvhf.com>
Re: [HACKERS] Re: HISTORY for 6.5.2
> > 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

Mon, 20 Sep 1999 21:55:17 -0400 (EDT)
Bruce Momjian <maillist@candle.pha.pa.us>
Re: [HACKERS] Re: HISTORY for 6.5.2
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 


Mon, 20 Sep 1999 23:10:58 -0300 (ADT)
The Hermit Hacker <scrappy@hub.org>
Re: [HACKERS] Re: HISTORY for 6.5.2
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 


Mon, 20 Sep 1999 23:13:07 -0300 (ADT)
The Hermit Hacker <scrappy@hub.org>
Re: [HACKERS] Re: HISTORY for 6.5.2
> 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

Mon, 20 Sep 1999 22:47:38 -0400 (EDT)
Bruce Momjian <maillist@candle.pha.pa.us>
Re: [HACKERS] Re: HISTORY for 6.5.2
> 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

Tue, 21 Sep 1999 05:59:54 +0000
Thomas Lockhart <lockhart@alumni.caltech.edu>
Re: [HACKERS] Re: HISTORY for 6.5.2
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 


Tue, 21 Sep 1999 03:14:40 -0300 (ADT)
The Hermit Hacker <scrappy@hub.org>
Re: [HACKERS] Re: HISTORY for 6.5.2
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

Tue, 21 Sep 1999 09:50:59 +0300
Hannu Krosing <hannu@tm.ee>
Re: [HACKERS] Re: HISTORY for 6.5.2
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
==========================================================================




Tue, 21 Sep 1999 05:27:25 -0400 (EDT)
Vince Vielhaber <vev@michvhf.com>
Re: [HACKERS] Re: HISTORY for 6.5.2
> > 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

Tue, 21 Sep 1999 10:01:40 -0400 (EDT)
Bruce Momjian <maillist@candle.pha.pa.us>
Re: [HACKERS] Re: HISTORY for 6.5.2
> 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

Tue, 21 Sep 1999 10:02:27 -0400 (EDT)
Bruce Momjian <maillist@candle.pha.pa.us>
Re: [HACKERS] Re: HISTORY for 6.5.2
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 


Tue, 21 Sep 1999 11:45:49 -0300 (ADT)
The Hermit Hacker <scrappy@hub.org>
Re: [HACKERS] Re: HISTORY for 6.5.2
> > 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

Tue, 21 Sep 1999 10:52:16 -0400 (EDT)
Bruce Momjian <maillist@candle.pha.pa.us>
Re: [HACKERS] Re: HISTORY for 6.5.2]
> > 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

Tue, 21 Sep 1999 15:21:31 +0000
Thomas Lockhart <lockhart@alumni.caltech.edu>
Re: [HACKERS] Re: HISTORY for 6.5.2]
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

Tue, 21 Sep 1999 12:05:51 -0400
Lamar Owen <lamar.owen@wgcr.org>
Re: [HACKERS] Re: HISTORY for 6.5.2
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

Tue, 21 Sep 1999 12:18:40 -0400
Lamar Owen <lamar.owen@wgcr.org>
Re: [HACKERS] Re: HISTORY for 6.5.2
   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

Tue, 21 Sep 1999 10:35:33 -0600 (MDT)
Brook Milligan <brook@biology.nmsu.edu>
Re: [HACKERS] Re: HISTORY for 6.5.2
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
==========================================================================




Tue, 21 Sep 1999 12:44:58 -0400 (EDT)
Vince Vielhaber <vev@michvhf.com>
Re: [HACKERS] Re: HISTORY for 6.5.2
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

Tue, 21 Sep 1999 13:14:50 -0400
Lamar Owen <lamar.owen@wgcr.org>
Re: [HACKERS] Re: HISTORY for 6.5.2
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 


Tue, 21 Sep 1999 16:02:55 -0300 (ADT)
The Hermit Hacker <scrappy@hub.org>
Re: [HACKERS] Re: HISTORY for 6.5.2]
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 


Tue, 21 Sep 1999 16:19:44 -0300 (ADT)
The Hermit Hacker <scrappy@hub.org>
Re: [HACKERS] Re: HISTORY for 6.5.2
>    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

Tue, 21 Sep 1999 15:26:08 -0400 (EDT)
Bruce Momjian <maillist@candle.pha.pa.us>
Re: [HACKERS] Re: HISTORY for 6.5.2
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
Tue, 21 Sep 1999 23:46:19 +0200 (CEST)
Peter Eisentraut <peter_e@gmx.net>
INSTALL file (was Re: [HACKERS] Re: HISTORY for 6.5.2)

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



Tue, 21 Sep 1999 17:59:07 -0400 (EDT)
Vince Vielhaber <vev@michvhf.com>
RE: INSTALL file (was Re: [HACKERS] Re: HISTORY for 6.5.2)
> > 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

Wed, 22 Sep 1999 15:48:29 +0000
Thomas Lockhart <lockhart@alumni.caltech.edu>
Re: [DOCS] INSTALL file (was Re: [HACKERS] Re: HISTORY for 6.5.2)
> > > 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

Wed, 22 Sep 1999 12:45:49 -0400 (EDT)
Bruce Momjian <maillist@candle.pha.pa.us>
Re: [DOCS] INSTALL file (was Re: [HACKERS] Re: HISTORY for 6.5.2)

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

Tue, 28 Sep 1999 00:44:07 -0400 (EDT)
Bruce Momjian <maillist@candle.pha.pa.us>
Re: INSTALL file (was Re: [HACKERS] Re: HISTORY for 6.5.2)

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

Mon, 29 Nov 1999 18:16:33 -0500 (EST)
Bruce Momjian <pgman@candle.pha.pa.us>
Re: INSTALL file (was Re: [HACKERS] Re: HISTORY for 6.5.2)

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



Mon, 29 Nov 1999 18:28:46 -0500 (EST)
Vince Vielhaber <vev@michvhf.com>
Re: INSTALL file (was Re: [HACKERS] Re: HISTORY for 6.5.2)
> 
> 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

Mon, 29 Nov 1999 18:38:41 -0500 (EST)
Bruce Momjian <pgman@candle.pha.pa.us>
Re: INSTALL file (was Re: [HACKERS] Re: HISTORY for 6.5.2)