Slashdot discussion

Bruce Momjian wrote:

OK, thanks to the www.phpbuilder.com PostgreSQL/MySQL comparison, there
is another PostgreSQL/MySQL thread on shashdot.org. Looks interesting,
and of course, we are looking good too.

I stuck my two cents in of course. :)
I think most people are of the opinion that each too is good to fit a
certain niche. Without wanting to starta thread war I think postgres is
great, but for many people the learning curve is too great and thus
MySQL is a good introduction.
I think a lot of people get started in MySQL and move up to Postgres.

Cheers,
Graeme

Graeme Merrall wrote:

Without wanting to starta thread war I think postgres is
great, but for many people the learning curve is too great and thus
MySQL is a good introduction.

In what way is mysql easier to learn?

Chris Bitmead wrote:

Graeme Merrall wrote:

Without wanting to starta thread war I think postgres is
great, but for many people the learning curve is too great and thus
MySQL is a good introduction.

Well speaking personally I found the documentation for MySQL better, the
install process simpler and getting stuff done just generally easier.
Things like phpMyAdmin just aren't out there for postgres although the
pgsql port is a pretty damn fine effort and I've never seen anything
like pgaccess for mysql. It may have been that I got my start in mSQL to
the transition was a little easier. Having said that, having now seen
Oracle and various other larger RDBMS's I understand the niches that
postgres and mysql fill. Postgres is now my DB of choice so I'm not
anti-mysql or anti-pgsql and if I don't like the docs that's fine, I
should just do something about it.
One thing that really cheeses me off are ppl going "Your documentation
sucks - do something about it" in an open source situation. There's the
CVS big fella, get writing. And if I was in a situation to do that, I
would.

Cheers,
Graeme

Bruce Momjian writes:

OK, thanks to the www.phpbuilder.com PostgreSQL/MySQL comparison, there
is another PostgreSQL/MySQL thread on shashdot.org. Looks interesting,
and of course, we are looking good too.

Is anyone else noticing this: Everytime this sort of thing comes up a
number of people invariably tell that they are using MySQL because it's
easier to install, and that PostgreSQL is difficult ("a pain") to install.

I've studied the MySQL installation instructions, and they don't strike me
as inherently simpler. Is it only perception, or what can we do better?

--
Peter Eisentraut Sernanders v�g 10:115
peter_e@gmx.net 75262 Uppsala
http://yi.org/peter-e/ Sweden

[ Charset ISO-8859-1 unsupported, converting... ]

Bruce Momjian writes:

OK, thanks to the www.phpbuilder.com PostgreSQL/MySQL comparison, there
is another PostgreSQL/MySQL thread on shashdot.org. Looks interesting,
and of course, we are looking good too.

Is anyone else noticing this: Everytime this sort of thing comes up a
number of people invariably tell that they are using MySQL because it's
easier to install, and that PostgreSQL is difficult ("a pain") to install.

I've studied the MySQL installation instructions, and they don't strike me
as inherently simpler. Is it only perception, or what can we do better?

I am confused by this also.

-- 
  Bruce Momjian                        |  http://candle.pha.pa.us
  pgman@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

Peter Eisentraut wrote:

I've studied the MySQL installation instructions, and they don't strike me
as inherently simpler. Is it only perception, or what can we do better?

Good question. My 2 cents...

1) The RPM-installed binaries that come with RH 6.0/6.1 can easily and
stealthly interfere with a src.tar.gz installation due to $PATH settings
(accidentally drawing on /bin/p* instead of /opt/pgsql/bin/p* ... Adding
detection to setup/install scripts might mitigate that.

2) Write an install wizard script that figures everything out for the
user based on questions/prompts.

Regards,
Ed Loehr

Peter Eisentraut <peter_e@gmx.net> writes:

I've studied the MySQL installation instructions, and they don't strike me
as inherently simpler. Is it only perception, or what can we do better?

IMHO it's partly a documentation problem, and partly a matter of people
not having looked at recent versions. A few years back it did take some
know-how to get Postgres installed.

I think the install-procedure docs in 7.0 are markedly better than they
were before, but they could still use further improvement.

Your work on configure/build/install scripts will help too of course ;-)

regards, tom lane

Is anyone else noticing this: Everytime this sort of thing comes up a
number of people invariably tell that they are using MySQL because it's
easier to install, and that PostgreSQL is difficult ("a pain") to install.

I've studied the MySQL installation instructions, and they don't strike me
as inherently simpler. Is it only perception, or what can we do better?

Possibly because for most people the process is a simple './configure;
make; make install'

Pgsql doesn't do this. Not the install process is any less better but
more because pgsql is a different beast and it's desifgned to work
differently. Just as (say) you can't install Oracle the same way as
MySQL, you can't install pgsql the same way either. The price of freedom
is enternal vigilance or in our case, the price of a more powerful DB is
a harder install :)
I had the ermm.. joy of installing Oracle in a dev situation and that
was much tricker then a pgsql install. env vars, directory set up -
sheesh :)

Cheers,
Graeme

Chris Bitmead wrote:

Graeme Merrall wrote:

Without wanting to starta thread war I think postgres is
great, but for many people the learning curve is too great and thus
MySQL is a good introduction.

In what way is mysql easier to learn?

To my point of view postgres is more easy to install and to start from.
I have
began to learn SQL and database with postgres95. It's still the most
easiest
database to install and to manage. The only thing it's to read
documentation
and Postgres is now very well documented. I have tried to run mysql
many
time but I never be patient enought to see it run. Beginers knowledge is
perhaps
more advanced than in Postgres mailing list because every one have a
friend
who have run mysql ... Not me :-)

On Tue, 11 Jul 2000, Graeme Merrall wrote:

Is anyone else noticing this: Everytime this sort of thing comes up a
number of people invariably tell that they are using MySQL because it's
easier to install, and that PostgreSQL is difficult ("a pain") to install.

I've studied the MySQL installation instructions, and they don't strike me
as inherently simpler. Is it only perception, or what can we do better?

Possibly because for most people the process is a simple './configure;
make; make install'

Pgsql doesn't do this. Not the install process is any less better but

huh? all i do is './configure;make;make install' ...

The Hermit Hacker wrote:

On Tue, 11 Jul 2000, Graeme Merrall wrote:

Is anyone else noticing this: Everytime this sort of thing comes up a
number of people invariably tell that they are using MySQL because it's
easier to install, and that PostgreSQL is difficult ("a pain") to install.

I've studied the MySQL installation instructions, and they don't strike me
as inherently simpler. Is it only perception, or what can we do better?

Possibly because for most people the process is a simple './configure;
make; make install'

Pgsql doesn't do this. Not the install process is any less better but

huh? all i do is './configure;make;make install' ...

I was referring to creating a new user etc which although mysql says it
would be a good idea to do, doesn't recommend from the start.
Hmm.. mind you, I've yet to do a v7.x install so I should just kepe my
trap shut :)

Bruce Momjian writes:

OK, thanks to the www.phpbuilder.com PostgreSQL/MySQL comparison, there
is another PostgreSQL/MySQL thread on shashdot.org. Looks interesting,
and of course, we are looking good too.

Is anyone else noticing this: Everytime this sort of thing comes up a
number of people invariably tell that they are using MySQL because it's
easier to install, and that PostgreSQL is difficult ("a pain") to install.

I've studied the MySQL installation instructions, and they don't strike me
as inherently simpler. Is it only perception, or what can we do better?

I am confused by this also.

Most of us tend to think of the development of the human species as if
the natural evolution was still a factor. It isn't anymore -- not so
much as it used to be. Back in the 19th century, what where the
chances of survival for a child born with a three-chamber heart? What
are these now?

Because of the ever diminishing evolutionary pressure, we become ever
more different and the concept of "bad" becomes murky. What once was
deadly is just abnormal today, and may even be OK tomorrow. How could
such an increasing variety pass unnoticed in the world of software,
which, like other tools in general, is arguably an extension of one's
organism?

I recall the days just about 20 years back, when Bill first emerged
with his BASIC. Who in their sane mind would then bet on its
survival, let alone see any commercial value in it? Even today, I know
lots of people who believe that Bill's BASIC was and is the best
software available to them. Who cares whether it works or not? It's
good. Period.

Bottom line -- we will eventually come to peace with the following
ugly facts:

* Bad things survive
* Useless things flourish
* The perception of the difficulty and simplicity is random
* The presence of features may repel users as much as the lack thereof
* A fairly large population *prefers* to do things in the hard way
* Free market is not automatically a smart one (look at the destiny
of the Dvorak keyboard or how they harass the GM food manufacturers).

Sad as all this is, we are going to leave with it. But you folks are
doing a great job!

--Gene

On Mon, Jul 10, 2000 at 08:40:27PM -0300, The Hermit Hacker wrote:

On Tue, 11 Jul 2000, Graeme Merrall wrote:

Is anyone else noticing this: Everytime this sort of thing comes up a
number of people invariably tell that they are using MySQL because it's
easier to install, and that PostgreSQL is difficult ("a pain") to install.

I've studied the MySQL installation instructions, and they don't strike me
as inherently simpler. Is it only perception, or what can we do better?

Possibly because for most people the process is a simple './configure;
make; make install'

Pgsql doesn't do this. Not the install process is any less better but

huh? all i do is './configure;make;make install' ...

And what about CVS?

bash-2.01$ cd ../pgsql
bash-2.01$ cvs -z9 update -dP
cvs [update aborted]: authorization failed: server postgresql.org rejected
access
bash-2.01$

-Egon

On Tue, 11 Jul 2000, Graeme Merrall wrote:

The Hermit Hacker wrote:

On Tue, 11 Jul 2000, Graeme Merrall wrote:

Is anyone else noticing this: Everytime this sort of thing comes up a
number of people invariably tell that they are using MySQL because it's
easier to install, and that PostgreSQL is difficult ("a pain") to install.

I've studied the MySQL installation instructions, and they don't strike me
as inherently simpler. Is it only perception, or what can we do better?

Possibly because for most people the process is a simple './configure;
make; make install'

Pgsql doesn't do this. Not the install process is any less better but

huh? all i do is './configure;make;make install' ...

I was referring to creating a new user etc which although mysql says it
would be a good idea to do, doesn't recommend from the start.
Hmm.. mind you, I've yet to do a v7.x install so I should just kepe my
trap shut :)

what? mysql let's you install as root?? :)

Just a comment on the Slashdot thread in general. I see us really
gaining on MySQL. Every month we get farther. Our rate of improvement
means we should leave them in the dust in 1-2 years.

-- 
  Bruce Momjian                        |  http://candle.pha.pa.us
  pgman@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

Peter Eisentraut wrote:

Bruce Momjian writes:

OK, thanks to the www.phpbuilder.com PostgreSQL/MySQL comparison, there
is another PostgreSQL/MySQL thread on shashdot.org. Looks interesting,
and of course, we are looking good too.

Is anyone else noticing this: Everytime this sort of thing comes up a
number of people invariably tell that they are using MySQL because it's
easier to install, and that PostgreSQL is difficult ("a pain") to install.

I've studied the MySQL installation instructions, and they don't strike me
as inherently simpler. Is it only perception, or what can we do better?

I think postgres is pretty easy to install. But for newbies, I think
mention should be made of "createuser" within the top level "INSTALL"
document. I think figuring out getting permission to create a database
is
something new users struggle a bit with.

Ed Loehr wrote:

Good question. My 2 cents...

1) The RPM-installed binaries that come with RH 6.0/6.1 can easily and
stealthly interfere with a src.tar.gz installation due to $PATH settings
(accidentally drawing on /bin/p* instead of /opt/pgsql/bin/p* ... Adding
detection to setup/install scripts might mitigate that.

That's a good point too. The INSTALL instructions should probably
contain
info on how to remove the default redhat or debian postgres
installation.

PostgreSQL:

Early on, it was quite a bit easier to find resources on the Internet
pertaining to MySQL. PostgreSQL info is out there, but I had to look a
bit further to find it. #mysql has much more activity than does
#postgresql, and since I prefer this method of communication over
mailing-lists, I found this to be very much in MySQL's favor.

The MySQL installation was somewhat more straightforward, but I didn't
find the PostgreSQL installation to be terribly intimidating.

I found MySQL to be significantly easier to use, however, once I started
experimenting with basic functionality. Most tasks in MySQL were
straightforward, so I was surprised to find that the same tasks in
PostgreSQL required much more effort (for example dropping a column, or
changing a column's data type). Further, I ran across a web-based
administrative program called WebMin that has a MySQL module. For a
novice user like myself, this kind of GUI simplifies things tremendously
and has really made working with MySQL much more pleasant in comparison.

As I learned more about the advanced features PostgreSQL offered, I
became concerned that MySQL might not be desirable for my application.
But I shortly realized that while PostgreSQL includes support for
advanced functionality such as Transactions, Subselects, Views, etc.,
it's not likely that I'll have the skills to take advantage of these
features for quite some time. And since it seems reasonable to expect
that MySQL will add many of these features in the near future, it makes
sense for me to go with MySQL for my application.

Of course, I reserve the right to change my mind. :-)

Peter Eisentraut wrote:

J.R. Belding wrote:

#mysql has much more activity than does #postgresql, and since I prefer
this method of communication over mailing-lists, I found this to be very
much in MySQL's favor.

Hmm. So which server do most postgresql people hang out on?

- Jeff

-- jdub@aphid.net --------------------------------- http://linux.conf.au/ --

linux.conf.au - coming to Sydney in January 2001

Installing Linux Around Australia - http://linux.org.au/installfest/

Bruce Momjian wrote:

Just a comment on the Slashdot thread in general. I see us really
gaining on MySQL. Every month we get farther. Our rate of improvement
means we should leave them in the dust in 1-2 years.

--
Bruce Momjian                        |  http://candle.pha.pa.us
pgman@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

Do you think it's a good idea to turn fsync off by default? I think most
first-time users will not know about turning fsync off when comparing
PostgreSQL and MySQL, and mistakenly judge PostgreSQL's slowness.

Regards,
Thomas.

Chris Bitmead wrote:

That's a good point too. The INSTALL instructions should probably
contain
info on how to remove the default redhat or debian postgres
installation.

For Debian, at least, this is a standard operation for any package; i.e.,
`dpkg --remove package' or `dpkg --purge package'. (--purge removes the
configuration files as well.) dpkg will complain if this would cause any
dependency to be violated.

I'm not sure that there's much use in putting this in the INSTALL; any
Debian user ought to know it any case, and Debian users don't generally
expect to read the upstream install files because they expect the
package maintainer to have handled anything necessary.
PostgreSQL is in the main Debian distribution, so there ought to be no
special issues about its installation or removal.

--
Oliver Elphick Oliver.Elphick@lfix.co.uk
Isle of Wight http://www.lfix.co.uk/oliver
PGP: 1024R/32B8FAA1: 97 EA 1D 47 72 3F 28 47 6B 7E 39 CC 56 E4 C1 47
GPG: 1024D/3E1D0C1C: CA12 09E0 E8D5 8870 5839 932A 614D 4C34 3E1D 0C1C
========================================
"I waited patiently for the LORD; and he inclined unto
me, and heard my cry. He brought me up also out of an
horrible pit, out of the miry clay, and set my feet
upon a rock, and established my goings. And he hath
put a new song in my mouth, even praise unto our God.
Many shall see it, and fear, and shall trust in the
LORD." Psalms 40:1-3

On Mon, 10 Jul 2000, J.R. Belding wrote:

PostgreSQL:

Early on, it was quite a bit easier to find resources on the Internet
pertaining to MySQL. PostgreSQL info is out there, but I had to look a
bit further to find it. #mysql has much more activity than does
#postgresql, and since I prefer this method of communication over
mailing-lists, I found this to be very much in MySQL's favor.

The MySQL installation was somewhat more straightforward, but I didn't
find the PostgreSQL installation to be terribly intimidating.

I found MySQL to be significantly easier to use, however, once I started
experimenting with basic functionality. Most tasks in MySQL were
straightforward, so I was surprised to find that the same tasks in
PostgreSQL required much more effort (for example dropping a column, or
changing a column's data type). Further, I ran across a web-based
administrative program called WebMin that has a MySQL module. For a
novice user like myself, this kind of GUI simplifies things tremendously
and has really made working with MySQL much more pleasant in comparison.

As I learned more about the advanced features PostgreSQL offered, I
became concerned that MySQL might not be desirable for my application.
But I shortly realized that while PostgreSQL includes support for
advanced functionality such as Transactions, Subselects, Views, etc.,

transactions:

begin;
select <value> from table;
update <value> in table;
end;

subselect:

SELECT a.field
FROM atable a, btable b
WHERE a.key = b.key
AND a.field2 IN ( SELECT field2
FROM ctable
WHERE field1 = value );

view:

CREATE VIEW a_field
SELECT a.field
FROM atable a, btable b
WHERE a.key = b.key
AND a.field2 IN ( SELECT field2
FROM ctable
WHERE field1 = value );

next? :)

it makes even more sense if you can put it into context of something, but
you get the idea, I hope :)

On Tue, 11 Jul 2000, Jeff Waugh wrote:

J.R. Belding wrote:

#mysql has much more activity than does #postgresql, and since I prefer
this method of communication over mailing-lists, I found this to be very
much in MySQL's favor.

Hmm. So which server do most postgresql people hang out on?

EFNet, channel #PostgreSQL ... always someone there, but activity on it
tends to be sporatic ...

The Hermit Hacker wrote:

On Mon, 10 Jul 2000, J.R. Belding wrote:

As I learned more about the advanced features PostgreSQL offered, I
became concerned that MySQL might not be desirable for my application.
But I shortly realized that while PostgreSQL includes support for
advanced functionality such as Transactions, Subselects, Views, etc.,

transactions:

begin;
select <value> from table;
update <value> in table;
end;

I never considered transactions an advanced feature. It's in
the basics of every relational database, coming in MySQL too
now.

The very first DB application I ever built for myself (using
PG 4.2 with a selfmade embedded PostQUEL preprocessor for C)
needed them already.

Might have an impact that I used Siemens ISAM files with
LEASY (a transactional layer with before/after image logging
capability on top of ISAM) in the BS2000 mainframe
environment for years before starting that project.

Anyway, I think the first thing anybody starting with
databases MUST learn is the concept of transactions! How many
people must be out in the world, considering themself an SQL
DB programmer, who learned the "basics" using past MySQL
releases? Father forgive them, because they don't know what
they do!

Jan

--

#======================================================================#
# It's easier to get forgiveness for being wrong than for being right. #
# Let's break this rule - forgive me. #
#================================================== JanWieck@Yahoo.com #

On Tue, Jul 11, 2000 at 12:24:20AM +0200, Peter Eisentraut wrote:

Is anyone else noticing this: Everytime this sort of thing comes up a
number of people invariably tell that they are using MySQL because it's
easier to install, and that PostgreSQL is difficult ("a pain") to install.

I've noticed that, too, but having installed them both (from source and from
packages), I have to say they're both "a pain" to install, at least as much
as anything is. Of course they are. They're complicated, and they're set
up to be flexible in installation on many machines.

It occurs to me, though, that many people may not install from source.
Maybe the RPMs are better for MySQL? I don't use 'em, so I don't know.

A

-- 
Andrew Sullivan                                      Computer Services
<sullivana@bpl.on.ca>                        Burlington Public Library
+1 905 639 3611 x158                                   2331 New Street
                                   Burlington, Ontario, Canada L7R 1J4

Once I ran into a guy who said that the postgres rpm was broken in Red Hat
5.2. This was when I was first getting into postgres. I spent some time
with it and realized that there were a number of things that had to be
done before it would work: creating the postgres users, initializing the
database, getting something into rc.d so it would boot up
automatically. The RPM was not broken, but it was a pain to get postgres
running unless you spent some time reading about it. My experience with
MySQL was less painful, although dealing with user permissions was more
complex.

----------------------------------------------------------------
Travis Bauer | CS Grad Student | IU |www.cs.indiana.edu/~trbauer
----------------------------------------------------------------

On Tue, 11 Jul 2000, Peter Eisentraut wrote:

Travis Bauer <trbauer@indiana.edu> writes:

Once I ran into a guy who said that the postgres rpm was broken in Red Hat
5.2. This was when I was first getting into postgres. I spent some time
with it and realized that there were a number of things that had to be
done before it would work: creating the postgres users, initializing the
database, getting something into rc.d so it would boot up
automatically. The RPM was not broken, but it was a pain to get postgres
running unless you spent some time reading about it. My experience with
MySQL was less painful, although dealing with user permissions was more
complex.

<snip>

The current Red Hat RPMS do create the postgres user and initialize
the database but doesn't define any of the environment variables. One
minor comment about the RPMS at the postgress website... The current
standard in Red Hat RPMS is to gzip all man pages because the man
program will automatically decompress them. If you run a RPM through
the program rpmlint, it will provide some useful warning about other
potential packing problems also...

--
Prasanth Kumar
kumar1@home.com

Travis Bauer wrote:

Once I ran into a guy who said that the postgres rpm was broken in Red Hat
5.2. This was when I was first getting into postgres. I spent some time
with it and realized that there were a number of things that had to be
done before it would work: creating the postgres users, initializing the
database, getting something into rc.d so it would boot up
automatically. The RPM was not broken, but it was a pain to get postgres

And, if most people's experience with the RedHat 5.2 RPM's is what
they're going on, they need to get with the program -- RH 5.2 shipped
PostgreSQL *6.3.2* which is absolutely ancient. Although, at the time,
6.3.2 was better than nothing.

The newer RPM's, hopefully, have corrected many of the problems that
existed with the _horrid_ 6.3.2 RPMset RedHat shipped with 5.1/5.2 (5.0
shipped *6.2.1*, which we won't even talk about -- although it was a
better RPM set than *6.1.1*, which is where I first experienced the 'Joy
of PostgreSQL') And, yes, the 6.3.2 RPMset was _horrid_ -- only there
were you entreated to the joy of an upgrade from one release of 6.3.2 to
another release of 6.3.2 totally breaking your database without warning
(thanks to the misconcieved postgresql-data subpackage).

The PostgreSQL group has come light years from the days of 6.1.1 -- I
cannot overemphasize that! Although, I won't go as far as the 6.5
release statement of "This represents the team's Final Mastery..." :-).

The documentation is several orders of magnitude better in 7.x than
6.1.1 or even as late as 6.3.2. The web site is also much much better
-- I still remember the logo breaking through the brick wall.

So, if most people's experience with PostgreSQL is that old.....

--
Lamar Owen
WGCR Internet Radio
1 Peter 4:11

"Prasanth A. Kumar" wrote:

Travis Bauer <trbauer@indiana.edu> writes:

Once I ran into a guy who said that the postgres rpm was broken in Red Hat
5.2. This was when I was first getting into postgres. I spent some time
with it and realized that there were a number of things that had to be
done before it would work: creating the postgres users, initializing the
database, getting something into rc.d so it would boot up
automatically. The RPM was not broken, but it was a pain to get postgres
running unless you spent some time reading about it. My experience with
MySQL was less painful, although dealing with user permissions was more
complex.

<snip>

The current Red Hat RPMS do create the postgres user and initialize
the database but doesn't define any of the environment variables.

And where should they be defined? /etc/profile, perhaps? Do I really
want ot go there with ENVVARS? (maybe I do -- maybe I don't :-))

One
minor comment about the RPMS at the postgress website... The current
standard in Red Hat RPMS is to gzip all man pages because the man
program will automatically decompress them. If you run a RPM through
the program rpmlint, it will provide some useful warning about other
potential packing problems also...

The only other rpmlint-able problem with the 7.0.2-2 set is the dangling
symlink of os.h in -devel (which will be fixed in the next release).
(and rpmlint's broken idea of file and directory permissions, which are
set the way they are for a reason...., and its broken idea of Vendor and
Distribution......).

The man pages are compressed in the latest RawHide release -- however,
due to my desire for cross-distribution capability with these RPM's,
since each distribution seems to have a different idea of where things
ought to go, and what format they ought to be in... --buildpolicy in the
latest RPM version fixes this sort of thing. The spec file itself is
built with this in mind, allowing for the manpages to be compressed in
any format or not compressed at all (due to the use of the appended * in
the %files listing). Of course, that is a build-time thing -- my goal is
not binary RPM compatibility, but SOURCE RPM compatibility.

But, thanks for the critique anyway! :-)

--
Lamar Owen
WGCR Internet Radio
1 Peter 4:11

On Tue, 11 Jul 2000, Lamar Owen wrote:

And, if most people's experience with the RedHat 5.2 RPM's is what
they're going on, they need to get with the program -- RH 5.2 shipped
PostgreSQL *6.3.2* which is absolutely ancient. Although, at the time,
6.3.2 was better than nothing.

Hello Lamar,

'Better than nothing' - hmm...

Perhaps better than MySQL? Definitely better than PROGRESS which is
what it replaced in my shop. I have one linux box running Pg up over
190 days - and it gets hammered on daily. Mind you I don't run RedHat
on production machines - it's a little too cute and a little too unstable.
I use slackware.

Anyway, I have some development boxes using newer versions of Pg
(both FBSD and Linux - even a RedHat workstation) but there is nothing
wrong with 6.3.2. Sure 7+ boasts more features and better performance
but there is nothing fatally flawed in 6.3.2. Trust me, 190 days for
a linux box running linux is pretty good. Especially when the users
are social workers - afraid of technology and overly fond of abusing the
text data type.

6.3.2 is certainly 'better than nothing' and, aside from slow vacuums,
I have no complaints. Of course, I have the old logo taped to the cover
of my notebook: a printout of the various pg manuals and Bruce's book.
Being a bit of a blockhead I kind of fancy to exploding bricks. ;-)

BTW, re the slashdot business...

Maybe MySQL is 'perceived' as easier to use than Pg - like Access (Abcess?)
is perceived as being friendlier than a real database. But the reality
is that MySQL always struck me as being more of a toy than an industrial
strength db - and installation isn't really that much easier.

I still recall my first build with Pg. The docs were very good and I
had it up and running on my first attempt. The only difficulty I had
was determining what IF to use. I started with ecpg then switched to
DBI. I think now I'd like to have a crack on the new and improved ecpg.
I see that Michael's done alot of work - of course it was always 'better
than nothing'! ;-)

Cheers,
Tom
--------------------------------------------------------------------
SVCMC - Center for Behavioral Health
--------------------------------------------------------------------
Thomas Good tomg@ { admin | q8 } .nrnet.org
IS Coordinator / DBA Phone: 718-354-5528
Fax: 718-354-5056
--------------------------------------------------------------------
Powered by: PostgreSQL s l a c k w a r e FreeBSD:
RDBMS |---------- linux The Power To Serve
--------------------------------------------------------------------

<snip>

The current Red Hat RPMS do create the postgres user and initialize
the database but doesn't define any of the environment variables.

And where should they be defined? /etc/profile, perhaps? Do I really
want ot go there with ENVVARS? (maybe I do -- maybe I don't :-))

If it were done, you would put it into a separate file in
/etc/profile.d thus making it easy to implement in RPMS.

One
minor comment about the RPMS at the postgress website... The current
standard in Red Hat RPMS is to gzip all man pages because the man
program will automatically decompress them. If you run a RPM through
the program rpmlint, it will provide some useful warning about other
potential packing problems also...

The only other rpmlint-able problem with the 7.0.2-2 set is the dangling
symlink of os.h in -devel (which will be fixed in the next release).
(and rpmlint's broken idea of file and directory permissions, which are
set the way they are for a reason...., and its broken idea of Vendor and
Distribution......).

I didn't specifically mean to imply there were huge problems with the
RPMS nor do I necessarily agree with all the warnings in rpmlint but I
think it is a good practice to run it in general once before releasing
RPMS because it can catch comman mistakes.

Actually, I kind of hate the fact that rpmlint exists... I'm the kind
of person who gets obsessed over compiler warnings and such in my own
code or annoyed of all the changed files when you do 'rpm -Va' so
rpmlint is just other thing for me to 'worry' about...

The man pages are compressed in the latest RawHide release -- however,
due to my desire for cross-distribution capability with these RPM's,
since each distribution seems to have a different idea of where things
ought to go, and what format they ought to be in... --buildpolicy in the
latest RPM version fixes this sort of thing. The spec file itself is
built with this in mind, allowing for the manpages to be compressed in
any format or not compressed at all (due to the use of the appended * in
the %files listing). Of course, that is a build-time thing -- my goal is
not binary RPM compatibility, but SOURCE RPM compatibility.

<snip>

Are these new features in RPM 4.0? I was trying to install them from
RawHide and couldn't because my RPM is too old.

--
Prasanth Kumar
kumar1@home.com

Thomas Good wrote:

On Tue, 11 Jul 2000, Lamar Owen wrote:

And, if most people's experience with the RedHat 5.2 RPM's is what
they're going on, they need to get with the program -- RH 5.2 shipped
PostgreSQL *6.3.2* which is absolutely ancient. Although, at the time,
6.3.2 was better than nothing.

Hello Lamar,

'Better than nothing' - hmm...

6.3.2 is certainly 'better than nothing' and, aside from slow vacuums,
I have no complaints. Of course, I have the old logo taped to the cover
of my notebook: a printout of the various pg manuals and Bruce's book.
Being a bit of a blockhead I kind of fancy to exploding bricks. ;-)

At the time of 6.1.1, there really was 'nothing' else that would work
for me, Free Software-wise. MySQL/mSQL wouldn't work, as they weren't
supported by AOLserver, nor did they do transactions (both of those
shortcomings have been/are being fixed). Sybase wasn't yet gratis, nor
was Interbase -- there was _nothing_ else. PostgreSQL was the only game
in town if you wanted a resonably complete RDBMS (although, 6.1.1 wasn't
really up to the standards of being an RDBMS).

At the time of 6.3.2, MySQL/mSQL/Sybase/Interbase were still not
contenders, as they either weren't 'Free' or weren't supported by
AOLserver. PostgreSQL (since Postgres95 1.01) was and is supported,
although as of AOLserver 2.2.1, you had to have at least PostgreSQL
6.2.1.

6.3.2 was a quantum leap forward, as subselects were finally (and
functionally!) implemented. However, the documentation was not really
polished -- certainly not what it is now.

But, my problem was never with PostgreSQL itself -- it was with the
braindead RPM's that had oddball dependencies and oddball behavior. Not
to mention the fact that until 6.3.2 RedHat Linux and PostgreSQL weren't
the closest of friends. The 6.3.1 version was by far the worst version
of the RPMs ever -- but that was as much the fault of RedHat as of
PostgreSQL. The 6.4.2 RPMs that shipped with RedHat 6.0 were also not
thought of very highly....

In fact, I upgraded from 6.3.2 to 6.5.2, skipping 6.4.x altogether.
MVCC made the difference, and the difference was GOOD. 6.5 was the real
standout release, in my book, that made the world of difference -- and I
was glad I had perservered until then.

Now you have OpenACS on AOLserver, which _requires_ PostgreSQL 7.0.x or
above.....

--
Lamar Owen
WGCR Internet Radio
1 Peter 4:11

Oliver Elphick wrote:

I'm not sure that there's much use in putting this in the INSTALL; any
Debian user ought to know it any case,

The first rule of documentation: Don't assume what the user knows. It's
a one-liner to tell them, so just do it.

Chris Bitmead wrote:

Oliver Elphick wrote:

I'm not sure that there's much use in putting this in the INSTALL; any
Debian user ought to know it any case,

The first rule of documentation: Don't assume what the user knows. It's
a one-liner to tell them, so just do it.

As a Debian user I'm afraid I'd have to agree with Oliver on this - the
tools for installing / removing / purging Debian packages are there.
The documentation for them is there. If a person is using Debian and
has managed to install PostgreSQL then they know how to remove it or
purge it - it doesn't (in this case) belong in the PostgreSQL
documentation.

Cheers,
Andrew.
--
_____________________________________________________________________
Andrew McMillan, e-mail: Andrew@cat-it.co.nz
Catalyst IT Ltd, PO Box 10-225, Level 22, 105 The Terrace, Wellington
Me: +64 (21) 635 694, Fax: +64 (4) 499 5596, Office: +64 (4) 499 2267

eschmid+sic@s.netic.de wrote:

huh? all i do is './configure;make;make install' ...

And what about CVS?

Have you changed the CVSROOT since it was changed between 7.0.0 and
7.0.2?

My nightly CVS mirrors have worked perfectly for a long time -- that is,
once I got the CVSROOT change properly done.
--
Lamar Owen
WGCR Internet Radio
1 Peter 4:11

On Tue, 11 Jul 2000, The Hermit Hacker wrote:

#mysql has much more activity than does #postgresql, and since I prefer
this method of communication over mailing-lists, I found this to be very
much in MySQL's favor.

Hmm. So which server do most postgresql people hang out on?

EFNet, channel #PostgreSQL ... always someone there, but activity on it
tends to be sporatic ...

We also have quite a few PostgreSQL people in EFnet's #Linux, along with a
nice little bot called 'helper' that consults a PostgreSQL database for
knowledgebase (and THEN some) stuff. Just make sure you join #linux with
identd on; we've had a lot of problems with people abusing open proxies.

---
Howie <caffeine@toodarkpark.org> URL: http://www.toodarkpark.org
"Programming today is a race between software engineers striving to
build bigger and better idiot-proof programs, and the Universe trying
to produce bigger and better idiots. So far, the Universe is winning."

On Mon, 10 Jul 2000, Bruce Momjian wrote:

Just a comment on the Slashdot thread in general. I see us really
gaining on MySQL. Every month we get farther. Our rate of improvement
means we should leave them in the dust in 1-2 years.

Especially with:

- Tablespace support (oh god would I love this)
- not having to pgdump in order to do a major version upgrade (tricky, i
know)

Who would I talk to about (partially) funding these, btw? or is that no
longer a concern with Great Bridge ?

---
Howie <caffeine@toodarkpark.org> URL: http://www.toodarkpark.org
"Programming today is a race between software engineers striving to
build bigger and better idiot-proof programs, and the Universe trying
to produce bigger and better idiots. So far, the Universe is winning."

Howie <caffeine@toodarkpark.org> writes:

Who would I talk to about (partially) funding these, btw? or is that no
longer a concern with Great Bridge ?

Great Bridge isn't actually up-and-running yet, AFAICT, so PostgreSQL
Inc would be the only likely place to funnel cash into a near-term
development project. (Or you could maybe make a personal agreement
with some key developer, but in the current state of affairs that's
difficult because we all have other full-time jobs...)

regards, tom lane

eschmid+sic@s.netic.de wrote:

On Mon, Jul 10, 2000 at 08:40:27PM -0300, The Hermit Hacker wrote:

On Tue, 11 Jul 2000, Graeme Merrall wrote:

Is anyone else noticing this: Everytime this sort of thing comes up a
number of people invariably tell that they are using MySQL because it's
easier to install, and that PostgreSQL is difficult ("a pain") to install.

I've studied the MySQL installation instructions, and they don't strike me
as inherently simpler. Is it only perception, or what can we do better?

Possibly because for most people the process is a simple './configure;
make; make install'

Pgsql doesn't do this. Not the install process is any less better but

huh? all i do is './configure;make;make install' ...

And what about CVS?

bash-2.01$ cd ../pgsql
bash-2.01$ cvs -z9 update -dP
cvs [update aborted]: authorization failed: server postgresql.org rejected
access
bash-2.01$

What does "echo $CVS_RSH" report? Marc is an Admin, not a
Wannabe. So access is restricted to ssh connections and cvs
uses rsh by default. If you tell me that MySQL's CVS is
accessible with rsh, let's think of a totally different way
to get rid of this entire discussion ...

Jan

--

#======================================================================#
# It's easier to get forgiveness for being wrong than for being right. #
# Let's break this rule - forgive me. #
#================================================== JanWieck@Yahoo.com #

Tom's right that Great Bridge doesn't have a shipping product yet, or a
website that has a whole lot to say for that matter. But there's a lot going
on behind the curtain over the summer that we'll be sharing with everyone over
the next few months.

In the meantime, if anyone would like to talk off-list about specific
development priorities, either in PostgreSQL itself or related tools,
interfaces, etc., please feel free to contact me directly.

And I'll reiterate once again: Any code we write will go straight into the
patch bucket like everyone else. We'll work with the folks on the -hackers
list to make sure that we don't go off and do anything stupid too :)

Thanks,

Ned Lilly
VP, Hacker Relations
Great Bridge, LLC

Tom Lane wrote: