Thread: Re: [HACKERS] [Fwd: SGVLLUG Oracle and Informix on Linux]

> On Tue, 21 Jul 1998, Bruce Momjian wrote:
>
> > > >   browse: <http://www.msnbc.com/news/181503.asp>. Thanks
> > > > to Greg Smith <greg@zoot.zzz.iipo.gtegs.com> for forwarding.
> > >
> > >  After shying away from the Linux platform for several months,
> > >  Informix Corp. will do an about face at its international users
> > >  conference in Seattle this week. Archrival Oracle Corp. is
> > >  expected to put its stamp on approval on Linux this week as
> > >  well, by announcing plans to do a Linux port of its Oracle
> > >  database, according to sources.
> > >
> > > Ooh. We're getting some serious company. Wonder if they'll be able to
> > > catch up with Postgres :)
> >
> > Ingres II is going to release on Linux too.  So now we have Informix,
> > Oracle, and Ingres to compete with.  Yikes.
>
>     Compete with?  They are all releasing free versions for Linux, vs
> the 10's of thousands of dollars they cost for the other operating
> systems? :)

[Informix, Oracle, and Ingres will be releasing versions of their
database engines under Linux in the future.]

OK, let's discuss this.  How does this affect us?  With all three
releasing around the same time, they really dilute themselves.  I can't
imagine most people trying more than one of the commercial alternatives.

Certain people will be tempted by a commercial SQL server, while others
will prefer us because of:

    features
    installed base
    open source
    support
    price(some are free)

Is there anything we need to do to prevent loss of user base?

Also, I was reading a thread on comp.databases that was discussing free
database alternatives, and no one had mentioned PostgreSQL.  We need
people to spread the word about PostgreSQL in all the forums they
frequent.  Just point them to www.postgresql.org, and they can look at
it themselves.  If they have heard of it, but don't use it, please tell
us why so we can clearly address those issues.  We need people to get
more involved in promoting us.

--
Bruce Momjian                          |  830 Blythe Avenue
maillist@candle.pha.pa.us              |  Drexel Hill, Pennsylvania 19026
  +  If your life is a hard drive,     |  (610) 353-9879(w)
  +  Christ can be your backup.        |  (610) 853-3000(h)

> OK, let's discuss this.  How does this affect us?  With all three
> releasing around the same time, they really dilute themselves.  I can't
> imagine most people trying more than one of the commercial alternatives.

I offer myself up as a case study...

I will likely use Oracle (or one of the other two) for some things, and
PostgreSQL for other things. Where expense is the key issue for a
customer, PostgreSQL. Where cost is less of a factor, Oracle.

I say this with these (mostly uninformed) assumptions in mind. Oracle's
ODBC driver is probably more complete. Oracle is better documented. Oracle
has a lot of related tools. Oracle offers training.

> Certain people will be tempted by a commercial SQL server, while others
> will prefer us because of:
>
>     features

As many posts I see to this list are "how do I do this" - "not
implemented, wait for a later version", I'm not sure why you would make
this claim. Again, I'm not a person who spends a great deal of time on
databases and I do consider myself uninformed.

>     installed base

PostgreSQL coming preinstalled with RedHat Linux 5.1 was the sole reason I
selected it. It was just too convenient.

>     open source

While I can appreciate this, it is not a requirement. Without a background
in database related knowledge, I would probably do more harm than good in
the short term, and no time for a long term investment in changes.

>     support

The mailing lists are nice. I appreciate them very much. There's probably
a mailing list for Oracle. What more is there for support?

>     price(some are free)

This is the significant advantage of PostgreSQL to me.


Bruce Tong                 |  Got me an office; I'm there late at night.
Systems Programmer         |  Just send me e-mail, maybe I'll write.
Electronic Vision / FITNE  |
zztong@laxmi.ev.net        |  -- Joe Walsh for the 21st Century

Bruce Momjian <maillist@candle.pha.pa.us> writes:

| OK, let's discuss this.  How does this affect us?  [...]
| Certain people will be tempted by a commercial SQL server, while others
| will prefer us because of:
|
|     features

Sorry, but I just don't buy this at the moment, for several reasons.

Don't get me wrong.  I like PostgreSQL, and think it could *eventually* kick
butt, but (as always, IMHO) it's Not Ready for Prime Time yet, not by a long
shot.  Let's look at some of the most problematic issues at the moment:

     *    No foreign keys.

    This is a real kicker for a lot of people.  Foreign keys are a big data
    integrity issue.  Fortunately, you can get around these with triggers,
    but:

     *    No SQL-based triggers.

    Triggers have to be written in C, and this is a big showstopper for a
    lot of people.

     *    No OUTER JOIN (left or right).

    Yes, you can simulate some of these with various UNION operators, but
    it's definitely off the SQL mainstream.

     *    32-bit OIDs.

    This pretty much takes PostgreSQL out of the running for large database
    projects.

     *    Hard-to-grok source code.

    Open source is great, but PostgreSQL source code still has great swaths
    of uncommented stretches of code, and that makes it much more difficult
    to do things like add esoteric types, or even extend the functionality
    of existing types.  I recognize that most of this is because it's still
    an amalgam of Postgres with the new stuff, but for PostgreSQL source to
    be a "selling point" of the software, it has to make the job of adding
    types and functionality *much* easier rather than merely possible.

There are a wide array of other issues, too; the simplistic security, view
limitations, administrational problems (eventually, for example, vacuum should
be unnecessary), analysis issues, replication issues, cross-server database
issues, index limitations, the lack of a good front end designer, the lack of a
good report designer, locking issues, and so on.

As I said, I like PostgreSQL.  It could eventually be a serious competitor to
Oracle.  I'd love to see it do so.  But this news of commercial competitors
will certainly eat away at a good portion of PostgreSQL's commercial customers,
and I can't see PostgreSQL reversing that trend unless 6.5 is a major leap
forward.

                        ---Ken McGlothlen
                           mcglk@serv.net

That is my case:

We have an Sun Ultra Sparc acting as a server for ~ 90 Pc runing M$ Dos or
Windows, almost all playing with a CAD program. I and a few other people
take care of the whole thing.

We need a SQL server but it is very hard for us to have approved a budget
of thousands of dollars to buy, traning and mantain a program like Informix
or Oracle to run in our server when we have to buy computers and programs
that runs CAD to allow ours  engineers to work.

So PostgreSQL realley save my life. It runs very well at Sun, I have a very
good support from all of you and I do not need all the stuff Oracle or
Informix offers.

I am now makeing a program that controls all our project files (more than
50.000) that are acessed by people that works where.(It was based in DBF
files). And the files and data will be accessible inside our office or
outside through browsers (CGI etc ...).

I will port a big calc program that will store all data into PostgreSQL.

I see PostgreSQL not only as a program for PC runing Linux but also as a
very good alternative for all unix box.

Roberto
>
>OK, let's discuss this.  How does this affect us?  With all three
>releasing around the same time, they really dilute themselves.  I can't
>imagine most people trying more than one of the commercial alternatives.
>

------------------------------------------------------------------
Eng. Roberto João Lopes Garcia         E-mail: roberto@mha.com.br
F. 55 11 848 9906   FAX  55 11 848 9955

MHA Engenharia Ltda
E-mail: mha@mha.com.br    WWW: http://www.mha.com.br

Av Maia Coelho Aguiar, 215 Bloco D     2 Andar
Centro Empresarial de Sao Paulo
Sao Paulo - BRASIL - 05805 000
-------------------------------------------------------------------

> Bruce Momjian <maillist@candle.pha.pa.us> writes:
>
> | OK, let's discuss this.  How does this affect us?  [...]
> | Certain people will be tempted by a commercial SQL server, while others
> | will prefer us because of:
> |
> |     features
>
> Sorry, but I just don't buy this at the moment, for several reasons.
>
> Don't get me wrong.  I like PostgreSQL, and think it could *eventually* kick
> butt, but (as always, IMHO) it's Not Ready for Prime Time yet, not by a long
> shot.  Let's look at some of the most problematic issues at the moment:
>
>      *    No foreign keys.
>
>     This is a real kicker for a lot of people.  Foreign keys are a big data
>     integrity issue.  Fortunately, you can get around these with triggers,
>     but:
>
>      *    No SQL-based triggers.
>
>     Triggers have to be written in C, and this is a big showstopper for a
>     lot of people.
>
>      *    No OUTER JOIN (left or right).
>
>     Yes, you can simulate some of these with various UNION operators, but
>     it's definitely off the SQL mainstream.
>
>      *    32-bit OIDs.
>
>     This pretty much takes PostgreSQL out of the running for large database
>     projects.
>
>      *    Hard-to-grok source code.
>
>     Open source is great, but PostgreSQL source code still has great swaths
>     of uncommented stretches of code, and that makes it much more difficult
>     to do things like add esoteric types, or even extend the functionality
>     of existing types.  I recognize that most of this is because it's still
>     an amalgam of Postgres with the new stuff, but for PostgreSQL source to
>     be a "selling point" of the software, it has to make the job of adding
>     types and functionality *much* easier rather than merely possible.
>
> There are a wide array of other issues, too; the simplistic security, view
> limitations, administrational problems (eventually, for example, vacuum should
> be unnecessary), analysis issues, replication issues, cross-server database
> issues, index limitations, the lack of a good front end designer, the lack of a
> good report designer, locking issues, and so on.
>
> As I said, I like PostgreSQL.  It could eventually be a serious competitor to
> Oracle.  I'd love to see it do so.  But this news of commercial competitors
> will certainly eat away at a good portion of PostgreSQL's commercial customers,
> and I can't see PostgreSQL reversing that trend unless 6.5 is a major leap
> forward.

You bring up some very good points here.

Consider what we are doing.  Commercial database vendors have teams of
full-time programmers, adding features to their databases, while we have
a volunteer group of part-time developers.

Many of the missing items you mention were only added to commercial
databases several years ago.  Our database only just added subselects,
which they had years ago.  Hard to imagine how we can keep up with
commercial systems.  Fortunately, we have many features they don't have,
which we inherited from Berkeley.

Actually, a database server sits on the software complexity scale just
below compilers and OS kernels.  This is not easy stuff.

As far as our source code, I think it is very clean.  I have made it a
personal project of mine to make it clear, so other people can
understand it and hence contribute.  I know our code is cleaner than
MySQL, and I would guess it is cleaner than many of the commercial SQL
engines. Our www site has a new "How PostgreSQL Processes a Query" paper
in the documentation section, that explains the basics of how the backend
works.

So where does that leave us.  We are open source, and those running
Linux, FreeBSD, etc. already have chosen open software, so we have an
advantage there.

We clearly are the most advanced "open source" database around.  We now
have "closed source" competition.  How do we meet that challenge?

--
Bruce Momjian                          |  830 Blythe Avenue
maillist@candle.pha.pa.us              |  Drexel Hill, Pennsylvania 19026
  +  If your life is a hard drive,     |  (610) 353-9879(w)
  +  Christ can be your backup.        |  (610) 853-3000(h)

maillist@candle.pha.pa.us (Bruce Momjian) writes:

| Consider what we are doing.  Commercial database vendors have teams of
| full-time programmers, adding features to their databases, while we have a
| volunteer group of part-time developers.

Oh!  I'd never *dream* of maligning the coders working on PostgreSQL.  For a
volunteer grass-roots effort, PostgreSQL is a paragon of virtue---one of the
reasons I like it.  And writing complex database packages of this sort isn't
exactly chimp-stuff, either---I think any of us would vouch for that.

Ultimately, the crux of the matter is this:  who are we *targeting* as our
competition?  If we're looking at the mSQL and mySQL camp, clearly PostgreSQL
stomps them both, from both the SQL support side and the data-security side.
(And yes, I'd agree that the code is *ever* so much neater than MySQL.)

But if we're trying to position ourselves as a viable alternative to the big
commercial ones, such as Oracle and Informix and Sybase and MS SQL Server, we
need to work on a lot of issues.  Open source is perceived in the business
community as a big risk, and not a benefit.  Even today, someone said to me,
"Oh, that's all we need, some Linux guru spending three or four hours on
compiling a new kernel rather than attending to his actual duties."  (Yes, I'll
be the first to admit that it was a stupid statement, but as a consultant, I
can't just say, "What a stupid statement."  It takes time to win over people
like this; you have to throw a product at them that makes them go, "Geez, that
was cool, and it saved us a lot of time and money.")

| Fortunately, we have many features they don't have, which we inherited from
| Berkeley.

Yes.  But at the moment, they have a bunch of *fundamental* features that we
don't have.  That's what worries me as far as general acceptance of PostgreSQL
by the business community.

| I have made it a personal project of mine to make it clear, so other people
| can understand it and hence contribute.

A lot more could be done.  More comments.  Breaking out individual datatypes
into their own modules (ready-made templates for new types that require
implementation in C!).  But to your (and others') credit, it's gotten quite a
bit cleaner just in the last year.

| We clearly are the most advanced "open source" database around.  We now
| have "closed source" competition.  How do we meet that challenge?

If we can clear up some of the glaring lackings in PostgreSQL by year-end, I
think it'll've been met pretty well.

On Tue, 21 Jul 1998, Bruce Tong wrote:

> I say this with these (mostly uninformed) assumptions in mind. Oracle's
> ODBC driver is probably more complete. Oracle is better documented. Oracle
> has a lot of related tools. Oracle offers training.

    What does Oracle's ODBC driver offer that ours currently doesn't?
    Have you looked at recent documentation?  It has changes
        dramatically over the past couple of months...
    What do you mean by "related tools"?
    Training in...administration?  We run it at my "real job", and
        Oracle *has* to offer training for administration...its a
        nightmare.

> >     features
>
> As many posts I see to this list are "how do I do this" - "not
> implemented, wait for a later version", I'm not sure why you would make
> this claim. Again, I'm not a person who spends a great deal of time on
> databases and I do consider myself uninformed.

    features != ANSI SQL compliance, right?  Again, what are we
missing that Oracle currently has...?

> >     support
>
> The mailing lists are nice. I appreciate them very much. There's probably
> a mailing list for Oracle. What more is there for support?

    My experience with paid support vs mailings lists tends to have me
much preferring mailing lists.  At least on a mailing list, you have a
good chance of finding someone that has already hit that same problem...

On Tue, 21 Jul 1998, Ken McGlothlen wrote:

> There are a wide array of other issues, too; the simplistic security,
> view limitations, administrational problems (eventually, for example,
> vacuum should be unnecessary), analysis issues, replication issues,
> cross-server database issues, index limitations, the lack of a good
> front end designer, the lack of a good report designer, locking issues,
> and so on.

    Alot of good points here, and some not so good...last I checked,
vacuum was still required for Oracle, no?  Its been awhile since I've
looked at it from a DBA perspective, so this may no longer be the case...

    As for 'front end and report designers'...there are several of
them out there currently, most, from what I've seen, *look* good:

    MPSQL: http://troubador.com/~keidav/images/screenshots/sot.jpg
    MPMGR: http://troubador.com/~keidav/mpmgr.html
        - if nobody has checked out the screenshots on this,
          check it out
    EARPII: http://www.oswego.edu/~ddougher/EARP2
    PGAccess: http://www.flex.ro/pgaccess
        - does Forms, Reports and Scripts
    PGAdmin: http://www.vale-housing.co.uk/it/software
        - no screenshots, unfortunately :(
    GtkSQL: http://www.mygale.org/~bbrox/GtkSQL
    KPGsql: http://home.primus.baynet.de/mgeisler/kpgsql
        - KDE frontend

    If there are features within those that you feel are missing, talk
to the authors, offer to help...

    What I'd like to see, though, is a detailed version of your list
above.  For instance, what locking issues?  Low-level locking that Vadim
is working on for v6.4?  What analysis issues?  If we could get the list
above with explanations of each, then Bruce can add them to the TODO list.
Without explanations, some, if not all, will sit there forever since
nobody will understand *what* is being asked :)

    Some of them might be small, no brainer additions that nobody
thought about...*shrug*

On Tue, 21 Jul 1998, Bruce Momjian wrote:

> We clearly are the most advanced "open source" database around.  We now
> have "closed source" competition.  How do we meet that challenge?

    You want an honest answer?  We don't.  Or, at least, we don't
think of it as meeting a challenge.

    We've spent the past, what, 2 years now, building PostgreSQL up to
something that we (the developers) are proud to work with and support, and
are confident in both using, and promoting for use, in real, production
environments.

    Oracle now comes along and says that it is going to have a
Linux-binary distribution available.  So?  How much is that binary going
to cost?  And what sort of licensing is provided?

    How many ppl are going to flock to Oracle because all of a sudden
they have a Linux port of it?  I just checked their list of 'supported
platforms', and here at the University, we run almost a half a dozen of
them (Win95, WinNT, Solaris x86, Sparc/Solaris, Netware)...its not as if I
don't have a machine that I can pay the same price for Oracle and run it
on them...

    Continue our trend...continuing listening to the ppl asking for
various "reasonable" features and working towards providing them.  I
support free/open software because, IMHO, the software is generally better
written, and more featured, because those that are developing it are doing
so because they *enjoy* what they are doing, they have a passion for
it...not because some large company is paying them to do it.

    IMHO, the most important thing that is happening right now is
Vadim's work at getting LLL in place for v6.4.  To me, that is as
important, if not more so, in a 'multi-user, concurrent' system as
transactions are, as on a multi-user system, it would be a performance
increase due to less ppl having to wait to make changes...

    I would like to see Ken's list of missing items expanded with
explanations and added to the TODO list, as appropriate, since I think he
brought up alot of good points, but I think that "panick'ng" because
Oracle has announced an upcoming release of a Linux binary is
counter-productive...

>
>         Oracle now comes along and says that it is going to have a
> Linux-binary distribution available.  So?  How much is that binary going
> to cost?  And what sort of licensing is provided?
--

What version of Linux? What Platform ? Full featured?

Don't kid yourselves about Oracle. Take it from someone who participates
on a Linux Mailing list also: There are countless versions of Linux out
there, running on every platform ever invented. Oracle would have to
release source code ( ha ha) to be a true linux port. I run LinuxPPC on
a power mac, and if they port to this then I will eat a huge plate of
crow.



-----------------------------------------------------------------
|John Dzilvelis                                                 |
-----------------------------------------------------------------

My comments are driven by perceptions. I admit they're uninformed. The
topic is advertising PostgreSQL, so my perceptions are relevant. Educate
me and the masses about your product. I'm hear because I think PostgreSQL
is a useful tool.

> > I say this with these (mostly uninformed) assumptions in mind. Oracle's
> > ODBC driver is probably more complete. Oracle is better documented. Oracle
> > has a lot of related tools. Oracle offers training.
>
> What does Oracle's ODBC driver offer that ours currently doesn't?

I just tried it for the first time last week. It failed to perform a
simple query. I need to double check my work yet. The Oracle ODBC driver
has _probably_ been around for a while and has _probably_ been better
tested perhaps simply by raw numbers of users.

> Have you looked at recent documentation? It has changed
> dramatically over the past couple of months...

I like to think I check your docs regularly, but I'm sure there's stuff I
miss. From my experience documentation is examples, HOWTO's, web sites,
and man pages which are all good approaches. The trouble is there is no
place which coordinates this. Searches tend to be a brute force effort for
me because I do not yet understand how the material is organized. I'm sure
if you've been around PostgreSQL for a couple of years you know the sorts
of things to expect to find in the man pages. To me, I never would have
thought to search the man pages for GRANT and REVOKE, or any SQL for that
matter.

In fact, documentation is probably the only place I can help your
development effort at this time since I cannot see the big picture. Hence,
the journal I'm keeping could be turned into a tutorial, which I suppose
it actually my goal.

> What do you mean by "related tools"?

Good question. What is Oracle Power Objects? What is Oracle/2000? I see
these things advertised. What do they do, and is an equivalent available
for PostgreSQL assuming it is a relavent product?

> Training in...administration?  We run it at my "real job", and
> Oracle *has* to offer training for administration...its a
> nightmare.

Administration, yes.

> > >     features
> >
> > As many posts I see to this list are "how do I do this" - "not
> > implemented, wait for a later version", I'm not sure why you would make
> > this claim. Again, I'm not a person who spends a great deal of time on
> > databases and I do consider myself uninformed.
>
> features != ANSI SQL compliance, right?

I suppose ANSI SQL is the heart of it.

> Again, what are we missing that Oracle currently has...?

If you offer the same features, then list those features in a comparison
on your web site. Take a "See... we do everything Oracle does."

> > >     support
> >
> > The mailing lists are nice. I appreciate them very much. There's probably
> > a mailing list for Oracle. What more is there for support?
>
>     My experience with paid support vs mailings lists tends to have me
> much preferring mailing lists.  At least on a mailing list, you have a
> good chance of finding someone that has already hit that same problem.

That's my experience too. Notice I didn't mention paid support. My point
here is if there's a list for Oracle, then you are the same in this
category.


Bruce Tong                 |  Got me an office; I'm there late at night.
Systems Programmer         |  Just send me e-mail, maybe I'll write.
Electronic Vision / FITNE  |
zztong@laxmi.ev.net        |  -- Joe Walsh for the 21st Century

On Wed, 22 Jul 1998, Bruce Tong wrote:

> My comments are driven by perceptions. I admit they're uninformed. The
> topic is advertising PostgreSQL, so my perceptions are relevant. Educate
> me and the masses about your product. I'm hear because I think PostgreSQL
> is a useful tool.

    Perceptions from the 'admittedly uninformed' helps...:)

> > > I say this with these (mostly uninformed) assumptions in mind. Oracle's
> > > ODBC driver is probably more complete. Oracle is better documented. Oracle
> > > has a lot of related tools. Oracle offers training.
> >
> > What does Oracle's ODBC driver offer that ours currently doesn't?
>
> I just tried it for the first time last week. It failed to perform a
> simple query. I need to double check my work yet. The Oracle ODBC driver
> has _probably_ been around for a while and has _probably_ been better
> tested perhaps simply by raw numbers of users.

    Have you mentioned this on pgsql-interfaces@postgresql.org?  David
and Bryon are both very vocal over there, and are quick to pop up to help
those using the ODBC drivers, as they are the ones that are developing it.

> > Have you looked at recent documentation? It has changed
> > dramatically over the past couple of months...
>
> I like to think I check your docs regularly, but I'm sure there's stuff I
> miss. From my experience documentation is examples, HOWTO's, web sites,
> and man pages which are all good approaches. The trouble is there is no
> place which coordinates this. Searches tend to be a brute force effort for
> me because I do not yet understand how the material is organized. I'm sure
> if you've been around PostgreSQL for a couple of years you know the sorts
> of things to expect to find in the man pages. To me, I never would have
> thought to search the man pages for GRANT and REVOKE, or any SQL for that
> matter.
>
> In fact, documentation is probably the only place I can help your
> development effort at this time since I cannot see the big picture. Hence,
> the journal I'm keeping could be turned into a tutorial, which I suppose
> it actually my goal.

    Any comments, opinions or suggested changes is welcome...are you
on the pgsql-docs mailing list?

    As for your perception of the documentation, have you checked out:

        http://www.postgresql.org/docs

    recently?  I've recently done a major cleanup of it so that the
links there are presented a little more clearly, but there are 5
guide/manuals listed right at the top that you might find sligthly more
informative those docs you list above...

 > > > What do you mean by "related tools"?
>
> Good question. What is Oracle Power Objects? What is Oracle/2000? I see
> these things advertised. What do they do, and is an equivalent available
> for PostgreSQL assuming it is a relavent product?

    I don't know, can't help you there...I don't use Oracle, so
someone with experience in that area will have to pop up and help :)

> > Training in...administration?  We run it at my "real job", and
> > Oracle *has* to offer training for administration...its a
> > nightmare.
>
> Administration, yes.

    So far, my experience with PostgreSQL has been that
'administrative functions' tend to be few, but there is a Administrator's
Guide that documents, I think, most of what you need to know.

    My opinion, though, tends to be that I learn more from a book,
then from other ppl, except for clarification of what I've read...

> > Again, what are we missing that Oracle currently has...?
>
> If you offer the same features, then list those features in a comparison
> on your web site. Take a "See... we do everything Oracle does.

    Hasn't been updated in awhile, but see:

    http://www.postgresql.org/comp-comparison.shtml

> That's my experience too. Notice I didn't mention paid support. My point
> here is if there's a list for Oracle, then you are the same in this
> category.

    That depends...we are only the same if you get similar support
through the Oracle list as you do here...

>     MPSQL: http://troubador.com/~keidav/images/screenshots/sot.jpg
>     MPMGR: http://troubador.com/~keidav/mpmgr.html
>         - if nobody has checked out the screenshots on this,
>           check it out

This one is looking *sooo* cool. Anybody knows of a good toolkit the
author can switch to? (he asks for suggestions on the page above). I think
up till now it was motif based? Is lesstif already up to this kind of
work? Is it easier to switch from motif to gtk than to switch to qt?

>     EARPII: http://www.oswego.edu/~ddougher/EARP2
>     PGAccess: http://www.flex.ro/pgaccess
>         - does Forms, Reports and Scripts
>     PGAdmin: http://www.vale-housing.co.uk/it/software
>         - no screenshots, unfortunately :(
>     GtkSQL: http://www.mygale.org/~bbrox/GtkSQL
>     KPGsql: http://home.primus.baynet.de/mgeisler/kpgsql
>         - KDE frontend

Maarten
_____________________________________________________________________________
| TU Delft, The Netherlands, Faculty of Information Technology and Systems  |
|                   Department of Electrical Engineering                    |
|           Computer Architecture and Digital Technique section             |
|                          M.Boekhold@et.tudelft.nl                         |
-----------------------------------------------------------------------------

> >       My experience with paid support vs mailings lists tends to have me
> > much preferring mailing lists.  At least on a mailing list, you have a
> > good chance of finding someone that has already hit that same problem.
>
>

Actually, I tend to end up supporting the product for which I am trying to be
supported...not that that is bad ;-)

Actually, most of my problems are answered before they happen, because I am
constantly monitoring the list.

As far as documentation goes, I think that for the most part what is there is
good.  Sometimes (and I realize I need to be more specific) it seems the very
thing you are looking for you can't find; in the end that generally has been an
issue of inexperience with SQL.  It seems to me, though, that there needs to be
some sort of documentation that takes a beginner write through the whole system
step by step and never leaving out the gory details, explaining things piece by
piece, until at the end of this the user has become an "expert".  Again, I need to
be more specific, and as I mull over this I might be able to be that, but now, I
don't see documentation that is really designed to take someone who doesn't know
squat about SQL and get them to the point where they are "experts".  Perhaps that
is not PostgreSQL's problem, but it would be nice.

Of course, if your write it, it doesn't mean they will read it ;-)

...james

> > > What does Oracle's ODBC driver offer that ours currently doesn't?
> >
> > I just tried it for the first time last week. It failed to perform a
> > simple query. I need to double check my work yet. The Oracle ODBC driver
> > has _probably_ been around for a while and has _probably_ been better
> > tested perhaps simply by raw numbers of users.
>
>     Have you mentioned this on pgsql-interfaces@postgresql.org?  David
> and Bryon are both very vocal over there, and are quick to pop up to help
> those using the ODBC drivers, as they are the ones that are developing it.

Nope. I wanted to check my work first. Its my first attempt at using the
ODBC driver and MS-Access has changed (for the worse interface-wise) a lot
since v1.1. It may even have something to do with the way I've declared
the tables on the PostgreSQL side.

[ Documentation ]

> Any comments, opinions or suggested changes is welcome...are you
> on the pgsql-docs mailing list?

No, but I will be shortly.

> As for your perception of the documentation, have you [recently] checked
> out:
>
> http://www.postgresql.org/docs

It's been a few weeks. I'll look again.

>     My opinion, though, tends to be that I learn more from a book,
> then from other ppl, except for clarification of what I've read...

I too learn a lot from books. But on new subjects, a short class covering
the idea behind the technology really helps. A little theory goes a long
way. I can figure out the "How" if I know the "Why."


Bruce Tong                 |  Got me an office; I'm there late at night.
Systems Programmer         |  Just send me e-mail, maybe I'll write.
Electronic Vision / FITNE  |
zztong@laxmi.ev.net        |  -- Joe Walsh for the 21st Century

> Sometimes (and I realize I need to be more specific) it seems the very
> thing you are looking for you can't find; in the end that generally has
> been an issue of inexperience with SQL.

Exactly. I'm learning SQL and PostgreSQL at the same time and it is
sometimes difficult for me to correctly assess what belongs with each. My
recent GRANT/REVOKE question was like this. I didn't think for a minute
that would be handled by SQL since databases were created and destroyed by
PostgreSQL utilities.

> It seems to me, though, that there needs to be some sort of
> documentation that takes a beginner write through the whole system step
> by step and never leaving out the gory details, explaining things piece
> by piece, until at the end of this the user has become an "expert".

Yes! I'm the loan PostgreSQL user here. In fact, I'm the only person
playing with a database. I'm the (completely unqualified) "expert" in the
building.

> Again, I need to be more specific, and as I mull over this I might be
> able to be that, but now, I don't see documentation that is really
> designed to take someone who doesn't know squat about SQL and get them
> to the point where they are "experts". Perhaps that is not PostgreSQL's
> problem, but it would be nice.
>
> Of course, if your write it, it doesn't mean they will read it ;-)

Tutorials get read. References get read if they're organized well enough
where the answer is found within a minute or two. Somebody who doesn't
know the proper term still has to be able to find the answer. That's
tricky, but those are the references which all people admire. Cross
referencing is essential. One of my favorite parts of the man pages is the
"See Also" section. This is because I usually get in the ball park on the
first try, but not exactly to the right page.


Bruce Tong                 |  Got me an office; I'm there late at night.
Systems Programmer         |  Just send me e-mail, maybe I'll write.
Electronic Vision / FITNE  |
zztong@laxmi.ev.net        |  -- Joe Walsh for the 21st Century

On Wed, 22 Jul 1998, The Hermit Hacker wrote:

>     Oracle now comes along and says that it is going to have a
> Linux-binary distribution available.  So?  How much is that binary going
> to cost?  And what sort of licensing is provided?

I think PostgreSQL will continue on as much as before, just as Linux is
continuing to put some competition to NT, because of its low cost and
flexibility.  Certainly many people will flock to Oracle, perhaps by
corporate pressure, perhaps for the support or interoperability with
other Oracle servers.  But it's not going to kill off PostgreSQL.

I'm happy that Oracle is being ported to Linux.  I'll probably never use
Oracle on Linux, but I think it will help get Linux wider recognition in
the enterprise environment.

And, how many 'supported platforms' of Oracle also support PostgreSQL?
PostgreSQL isn't a Linux only server.

>     Continue our trend...continuing listening to the ppl asking for
> various "reasonable" features and working towards providing them.  I
> support free/open software because, IMHO, the software is generally better
> written, and more featured, because those that are developing it are doing
> so because they *enjoy* what they are doing, they have a passion for
> it...not because some large company is paying them to do it.

A good point.

Brett W. McCoy
                                         http://www.lan2wan.com/~bmccoy
-----------------------------------------------------------------------
"The Number of UNIX installations has grown to 10, with more expected."
   -- The UNIX Programmer's Manual, 2nd Edition, June, 1972

On Wed, 22 Jul 1998, James Olin Oden wrote:
> As far as documentation goes, I think that for the most part what is there is
> good.  Sometimes (and I realize I need to be more specific) it seems the very
> thing you are looking for you can't find; in the end that generally has been an
> issue of inexperience with SQL.

It seems to me that the documentation assumes some knowledge of SQL.
I don't know if this was intended or not, but if a new user DOESN'T
know anything about SQL, they are not going to learn it from the
PostgreSQL manuals. Here are some basic examples:

The small section in the User's Manual on the SELECT command is
extremely short and neither explains nor gives examples for the many
basic things you can do with SELECT. So, for instance, from the
documentation, a new user will learn that he can select whatever
fields he wants from a table and tell it to select only those
records (tuples) which meet an exact criteria (suchandsuch <
'soandso' AND blahblah = 'blah'). But let's say that he wants to
select NOT all records that contain only 'blah' in the blahblah
field, but rather, all records that have 'blah' ANYWHERE WITHIN the
blahblah field? No where in the PostgreSQL documentation (that I
could find) will he be told that he can do "blahblah LIKE '%blah%'".

So now let's say he doesn't want it to be case sensative. Nowhere
that I could find do the manuals tell him that he can do "blahblah
~* 'blah'". In fact, I didn't know that ~* even existed until
someone on the list suggested I do a "\do" in psql to get a list of
all the operators. Do you see how it seems like that information is
hidden down in an obscure help command in one program rather than
being right there in the User's Manual? What the User's Manual needs
is a nice long detailed description WITH A LOT OF EXAMPLES of the
SELECT command. Instead it seems to just mention it in passing.

Now the man pages suffer the same problem that the entire man page
system suffers: it pretends to be an online representation of a
printed set of manuals, but it is missing one major feature of
printed manuals: A TABLE OF CONTENTS! Some of the man page info IS
in the HTML docs, but I think EVERYTHING in the man pages should be
in the HTML manuals, (possible better organized than man pages
allow).

Most of the sections in the manuals are simply too brief. Consider
the section in the Tutorial on Redirecting SELECT Queries. It
explains the idea as quickly as possible, gives ONE example, and is
done. This doesn't help new users much.

I think you see my point. If I knew more about PostgreSQL and SQL in
general, I'd offer to write some, but I'm just in the learning
process now.

   Cheers.
 --Dan D.

-----------------------------------------------------------------------
 Daniel G. Delaney                    The Louisville Times Chorus
 Dionysos@Dionysia.org                   www.LouisvilleTimes.org
 www.Dionysia.org/~dionysos/          Dionysia Design
 ICQ Number: 8171285                     www.Dionysia.com/design/
-----------------------------------------------------------------------
                   I doubt, therefore I might be.

The Hermit Hacker wrote:
>
> On Wed, 22 Jul 1998, Bruce Tong wrote:
>
> > My comments are driven by perceptions. I admit they're uninformed. The
> > topic is advertising PostgreSQL, so my perceptions are relevant. Educate
> > me and the masses about your product. I'm hear because I think PostgreSQL
> > is a useful tool.
>
>         Perceptions from the 'admittedly uninformed' helps...:)
>
> > > > I say this with these (mostly uninformed) assumptions in mind. Oracle's
> > > > ODBC driver is probably more complete. Oracle is better documented. Oracle
> > > > has a lot of related tools. Oracle offers training.
> > >
> > > What does Oracle's ODBC driver offer that ours currently doesn't?
> >
> > I just tried it for the first time last week. It failed to perform a
> > simple query. I need to double check my work yet. The Oracle ODBC driver
> > has _probably_ been around for a while and has _probably_ been better
> > tested perhaps simply by raw numbers of users.
>

I bet he has the old PostODBC driver -OR- there is a configuration
issue.
If the version of the driver he has begins with dot (like .21 or .30),
its ancient.
The latest version of the odbc driver at
http://www.insightdist.com/psqlodbc is 6.30.0247.

As long as we are mentioning the PostODBC, there is still a link under
the
"INFORMATION CENTRAL"-->"HOW TO"-->"INTERFACE DRIVERS FOR
PostgreSQL"-->ODBC Drivers for PostgreSQL.

This link takes you to "sunsite.unc.edu" which has outdated information
on it.
The ancient ODBC Drivers listed on this site are :

stud1.tuwien.ac.at/~e9025461
www.MageNet.com/postodbc/DOC

Is there anyway to correct this information and put the insight link on
there?

For that matter, is there anyway to point people who go to MageNet to
the right address, like a forward page?  This is important because Web
search engines (yahoo, alta-vista) will still send you to MageNet if you
search on odbc and postgres.

I wonder how many people go try the MageNet odbc driver and just give up
and try another dbms without even sending any mail to the lists?

Please, I would really appreciate a response.

Byron

> On Wed, 22 Jul 1998, James Olin Oden wrote:
> > As far as documentation goes, I think that for the most part what is there is
> > good.  Sometimes (and I realize I need to be more specific) it seems the very
> > thing you are looking for you can't find; in the end that generally has been an
> > issue of inexperience with SQL.
>
> It seems to me that the documentation assumes some knowledge of SQL.
> I don't know if this was intended or not, but if a new user DOESN'T
> know anything about SQL, they are not going to learn it from the
> PostgreSQL manuals. Here are some basic examples:
>
> The small section in the User's Manual on the SELECT command is
> extremely short and neither explains nor gives examples for the many
> basic things you can do with SELECT. So, for instance, from the
> documentation, a new user will learn that he can select whatever
> fields he wants from a table and tell it to select only those
> records (tuples) which meet an exact criteria (suchandsuch <
> 'soandso' AND blahblah = 'blah'). But let's say that he wants to
> select NOT all records that contain only 'blah' in the blahblah
> field, but rather, all records that have 'blah' ANYWHERE WITHIN the
> blahblah field? No where in the PostgreSQL documentation (that I
> could find) will he be told that he can do "blahblah LIKE '%blah%'".
>
> So now let's say he doesn't want it to be case sensative. Nowhere
> that I could find do the manuals tell him that he can do "blahblah
> ~* 'blah'". In fact, I didn't know that ~* even existed until
> someone on the list suggested I do a "\do" in psql to get a list of
> all the operators. Do you see how it seems like that information is
> hidden down in an obscure help command in one program rather than
> being right there in the User's Manual? What the User's Manual needs
> is a nice long detailed description WITH A LOT OF EXAMPLES of the
> SELECT command. Instead it seems to just mention it in passing.
>
> Now the man pages suffer the same problem that the entire man page
> system suffers: it pretends to be an online representation of a
> printed set of manuals, but it is missing one major feature of
> printed manuals: A TABLE OF CONTENTS! Some of the man page info IS
> in the HTML docs, but I think EVERYTHING in the man pages should be
> in the HTML manuals, (possible better organized than man pages
> allow).
>
> Most of the sections in the manuals are simply too brief. Consider
> the section in the Tutorial on Redirecting SELECT Queries. It
> explains the idea as quickly as possible, gives ONE example, and is
> done. This doesn't help new users much.
>
> I think you see my point. If I knew more about PostgreSQL and SQL in
> general, I'd offer to write some, but I'm just in the learning
> process now.
>

Good points.  The only comment I have is that the FAQ does now point to
several SQL tuturials on the web, and the psql \d commands are mentioned
as ways to find information about the system.  We don't list them in the
manual because they are always changing, because we are a
user-extensible system.  Every release has new types, so we just tell
people to use the \d commands.  I just improved them for 6.4 so the
output is clearer.

--
Bruce Momjian                          |  830 Blythe Avenue
maillist@candle.pha.pa.us              |  Drexel Hill, Pennsylvania 19026
  +  If your life is a hard drive,     |  (610) 353-9879(w)
  +  Christ can be your backup.        |  (610) 853-3000(h)

> > > > What does Oracle's ODBC driver offer that ours currently doesn't?
> > >
> > > I just tried it for the first time last week. It failed to perform a
> > > simple query. I need to double check my work yet. The Oracle ODBC driver
> > > has _probably_ been around for a while and has _probably_ been better
> > > tested perhaps simply by raw numbers of users.
>
> I bet he has the old PostODBC driver -OR- there is a configuration
> issue. If the version of the driver he has begins with dot (like .21
> or .30), its ancient.

> The latest version of the odbc driver at
> http://www.insightdist.com/psqlodbc is 6.30.0247.

While I was initially fooled by the old driver months ago, I have
v06-30-0247 according to the installer, postdrv.exe. I got this from the
web site you quoted.

I'm fairly certain I can recreate the circumstances, and I'll try to do so
today. I assume the "Interfaces" list is the place for this discussion.


Bruce Tong                 |  Got me an office; I'm there late at night.
Systems Programmer         |  Just send me e-mail, maybe I'll write.
Electronic Vision / FITNE  |
zztong@laxmi.ev.net        |  -- Joe Walsh for the 21st Century

scrappy@hub.org (The Hermit Hacker) writes:

| Alot of good points here, and some not so good...last I checked, vacuum was
| still required for Oracle, no?

Does Oracle even have a vacuum?  There's the COELESCE command, but it's hardly
*necessary*.

| As for 'front end and report designers'...there are several of them out there
| currently, most, from what I've seen, *look* good.

A lot of them "look good" at first glance.  The problem seems to be that the
implementations tend to be spotty and incomplete amongst the packages I've
looked at.  None of them are robust or complete enough for most commercial use.

| If there are features within those that you feel are missing, talk to the
| authors, offer to help...

I'm only speaking from one viewpoint:  is the product something I can recommend
for commercial use to my customers in the same breath as Oracle or Informix?
Would *I* use it, personally?  Of course; I like it, and don't mind getting my
hands dirty.  But most companies would balk.  They aren't balking at Linux or
FreeBSD, nor are they balking at Apache, so it's not just an avoidance of
open-source software.  They *would* balk at the lack of features, in spite of
PostgreSQL's cool stuff, and they'd also balk at the lack of facilities, and
they'll *really* balk on the stability issues.

| What I'd like to see, though, is a detailed version of your list above.  For
| instance, what locking issues?  Low-level locking that Vadim is working on
| for v6.4?

I'm not clear on the details of what Vadim is working on, but if it's page- or
row-level locking, that'd be it.  However, it's hard to responsibly recommend
something that hasn't been released yet.  (Hasn't stopped Microsoft, but I try
to be a bit more ethical than they are.  :)

| What analysis issues?  If we could get the list above with explanations of
| each, then Bruce can add them to the TODO list.  Without explanations, some,
| if not all, will sit there forever since nobody will understand *what* is
| being asked :)

Consider my wrist slapped.  :)

One thing I think that would psychologically help is to quit comparing
PostgreSQL with mSQL and MySQL.  The m*twins are cute, toy databases, and I
suspect that the general perception is that PostgreSQL is already more serious
than either one of those.  So enough with those comparisons.  Let's start
thinking about comparing PostgreSQL with its *real* competition:  Oracle,
Sybase, SQL Server, Informix, and others.

(Horrors! you say.  "They're commercial products, how can we compete?"  Apache
still has more than 50% of the web market, Linux and FreeBSD are serious
competitors to Solaris and HPs.  So we don't have millions of dollars for
marketing.  So we don't have hundreds of developers to throw at a project.  We
have something *else* they don't have:  a bunch of middle-management
business-as-usual MBA-drones.)

So.  Let's talk features.  (Hey!  www.postgresql.org is reporting "Document
contains no data."  How am I supposed to pull up the TODO list like this?)

Well, I'm gonna be guessing here, so please pardon me.

Reliability:  You don't need me to point out that a lot of work needs to be
done here.  These issues are tough ones to counter.  Why doesn't pg_dump
actually preserve everything?  (It's getting better, I know, but it's not there
right now.)  Why do you have to vacuum the database every night?  Questions
like that are tough to answer to people's satisfaction, and that's without even
going into things like memory leaks.

Crucial basics:  Views---they desperately need fixing up.  Foreign keys,
constraints, and SQL-language triggers are critical as well.  I think HAVING,
OUTER and INTERSECTS are being worked on.  Temporary tables---are those being
worked on?  Yes, I know, most of these are on the TODO list already, but their
current state of nonbeing is keenly felt, and hinders the cause quite a bit.

The draws:  These are the things that should be distinguishing PostgreSQL from
the rest of the pack.  The source code is a big draw, but it's still hard to
grok.  A concerted effort should be going on to document the code itself.
Breaking out built-in types into their own easy-to-locate files would also be
good, too; I had to work to find out how the box functions were defined, where
it would have been better to have a built-in-types directory with a file in
there named box.c, for example, with the data representation and the function
source all neatly bundled---then it would be *easy* to use that as a template
to come up with a different type.  (Believe me, if datetime had had such a
file, coming up with the equivalent of strftime() for that would have been a
whole lot easier.  As it is, I'm still trying to figure out how it's been
implemented with what time I have these days.)  There's a lot of clarification
that could be done here as far as making it easy to add user-contributed stuff,
which ultimately means that we can support more types---and that's a big draw.
(Imagine a type called `earthpoint' consisting of latitude and longitude, and
arrange to have a bunch of the point operators work properly; you might have a
northof function, and a westof function, and a distance function.  Then you
might add `earthregion' which parallels the polygon type.  So much for having
to sell this product to cartographers.  I'd love to create it, but right now, I
wouldn't have a *clue* where to put it, or how to start.  I might have the time
to read the source tree once I reduce my project load to just two or three, but
that's not going to happen anytime soon.)

Without a lot of the crucial basics and reliability issues addressed,
PostgreSQL is always going to be a big risk compared to Oracle et al, and
businesses (especially IS managers) *hate* risk.  Once those are taken care of,
the other features help sell the product, and we can start worry about things
like image and branding and a nice, polished corporate look and Kerberos
support and other frippery like that.  :)

(Which reminds me.  Is anyone interested in a rework of the PostgreSQL Program
Flow diagram?  My first rework is at

    http://www.serv.net/~mcglk/postgresql.gif (30973 bytes)
    http://www.serv.net/~mcglk/postgresql.jpg (41422 bytes)

([Take your pick.]  It's a little unclear, IMHO, so I came up with a second
draft at

    http://www.serv.net/~mcglk/postgresql1.gif (56856 bytes)
    http://www.serv.net/~mcglk/postgresql1.jpg (43292 bytes)

(Use as you like, if you like.)

                            ---Ken

>> Oracle now comes along and says that it is going to have a
>> Linux-binary distribution available.  So?  How much is that binary
>> going to cost?  And what sort of licensing is provided?

JohnDz> What version of Linux? What Platform ? Full featured?

I was asking myself the same question.



JohnDz> Don't kid yourselves about Oracle...
JohnDz> There are countless versions of Linux out there, running on
JohnDz> every platform ever invented.

Without starting a Linux-advocacy debate, I take exception to the
above statement :) I am under the impression that many of those Linux
ports are still rather experimental, and that there are still zillions
(!) of architectures that /don't/ yet have a Linux port.  Please
educate me if I am wrong!

\begin{rant}

One of the reasons I work with NetBSD is that it has /stable/ ports to
more than a dozen different architectures (CPUs) and even more
platforms (types of machines)!  I use two of them: i386 and MIPS/PMAX,
with a third in the running (waiting for some hardware): Mac68K.

I realise that there are people running Linux on Intel-based palmtops,
but that sort of thing is also happening with both NetBSD and FreeBSD.
Fair enough, Linux 2.x might have had much of the i386-specific guts
of Linux 1.x ripped out of it and replaced with more portable innards,
but NetBSD was built with that portability and code cleanliness from
the ground up!  Having looked at the source code for large chunks of
Linux and that for equivalent chunks of NetBSD, I know without a
shadow of a doubt which way I choose to favour!

Enough said, I really don't want to start a useless advocacy debate, I
acknowledge that the Linux phenomenon is fabulous---every bit as
fabulous as NetBSD's implementation---yet I feel that the rest of the
free UNIX community is neglected when Linux gets all the spotlight!

\end{rant}

PostgreSQL runs quite nicely on NetBSD, thank you very much, though I
have not yet the time nor the requirement to stress it very much---I
/did/ have a go with the embedded-SQL C preprocessor, and I conclude
from that experience that in comparison against the embedded-SQL
preprocessor for the InterBase product, ecpg produces very elegant C,
and is, in many ways, a far nicer tool.  On the other hand, the
InterBase tool implements a few more facilities, and as the DB of
choice for the project on which I am working those facilities had
precedence over my developing against PostgreSQL :(



JohnDz> Oracle would have to release source code ( ha ha) to be a true
JohnDz> linux port. I run LinuxPPC on a power mac, and if they port to
JohnDz> this then I will eat a huge plate of crow.

Here, here!

--Kevin.

> Exactly. I'm learning SQL and PostgreSQL at the same time and it is
> sometimes difficult for me to correctly assess what belongs with each. My
> recent GRANT/REVOKE question was like this. I didn't think for a minute
> that would be handled by SQL since databases were created and destroyed by
> PostgreSQL utilities.

In fact, they are handled by SQL: CREATE DATABASE and DROP DATABASE. The
createdb and destroydb tools just call these SQL statements....

Maarten

_____________________________________________________________________________
| TU Delft, The Netherlands, Faculty of Information Technology and Systems  |
|                   Department of Electrical Engineering                    |
|           Computer Architecture and Digital Technique section             |
|                          M.Boekhold@et.tudelft.nl                         |
-----------------------------------------------------------------------------

On Wed, 22 Jul 1998, Ken McGlothlen wrote:

> Does Oracle even have a vacuum?  There's the COELESCE command, but it's hardly
> *necessary*.

    I don't know, but I'll check at work tomorrow about this...and
reply accordingly...

> | As for 'front end and report designers'...there are several of them out there
> | currently, most, from what I've seen, *look* good.
>
> A lot of them "look good" at first glance.  The problem seems to be that
> the implementations tend to be spotty and incomplete amongst the
> packages I've looked at.  None of them are robust or complete enough for
> most commercial use.

    And you've, of course, discussed these failings with the authors
of the software itself?  Or did you do like most and just drop the
software as being incomplete?

    The only person so far that I've had experience with, as far as
'front-ends' are concerned, is Teo (PgAccess), who has been very
responsive to users requests for changes and improvements.  I imagine the
rest are similar in addressing requests, or, hell, make the improvement
yourself and ask them to add it into their source tree for future
releases.

    Its an "open software" model...no one person is responsible in
making it do what *you* want, except yourself.

    Its like a few weeks ago, I started playing with Xtrophy's ICQ
client.  It was missing features that I wanted, so I worked through the
code and added them in myself...submitted patches to the authors, which
they've included in the new release.

> | If there are features within those that you feel are missing, talk to the
> | authors, offer to help...
>
> I'm only speaking from one viewpoint:  is the product something I can
> recommend for commercial use to my customers in the same breath as
> Oracle or Informix?  Would *I* use it, personally?  Of course; I like
> it, and don't mind getting my hands dirty.  But most companies would
> balk.  They aren't balking at Linux or FreeBSD, nor are they balking at
> Apache, so it's not just an avoidance of open-source software.  They
> *would* balk at the lack of features, in spite of PostgreSQL's cool
> stuff, and they'd also balk at the lack of facilities, and they'll
> *really* balk on the stability issues.

    features are continuously being added and improved...how many
years has Oracle been working on it, and how much money have they sunk
into it?  We've been going, what, 2 years now?

    Lack of facilities?  Front-end interfaces?  They are out there, as
I listed before...they might be missing features you feel are required,
and I don't dispute that...but if everyone just writes them off, then the
author's have no reason, or desire, to maintain them.  Give the authors
feedback, offer them patches so that they don't have to work at adding
stuff you want, but they don't need and feel is a priority yet...

> I'm not clear on the details of what Vadim is working on, but if it's
> page- or row-level locking, that'd be it.  However, it's hard to
> responsibly recommend something that hasn't been released yet.  (Hasn't
> stopped Microsoft, but I try to be a bit more ethical than they are.  :)

    As do we...how many ppl out there have, to date, been severely
hampered by lack of 'row-level locking'?  IMHO, row-level locking will
give us a speed improvement as ppl won't be as queued on their requests,
but I *think* that that is the major thing it will provide...

> One thing I think that would psychologically help is to quit comparing
> PostgreSQL with mSQL and MySQL.  The m*twins are cute, toy databases,
> and I suspect that the general perception is that PostgreSQL is already
> more serious than either one of those.  So enough with those
> comparisons.  Let's start thinking about comparing PostgreSQL with its
> *real* competition:  Oracle, Sybase, SQL Server, Informix, and others.

    I don't quite agree here...I think MySQL/mSQL are required in any
comparison, to show what we do have that they don't.  They label
themselves an RDBMS, so I personally think that *not* including them would
be frowned upon by those looking at the comparison as being a slight.

    As for the comparisons, hey haven't been updated since
v6.2.1...I've asked once before, but is anyone actually interested in
working on updating and revising that?

> (Horrors! you say.  "They're commercial products, how can we compete?"
> Apache still has more than 50% of the web market, Linux and FreeBSD are
> serious competitors to Solaris and HPs.  So we don't have millions of
> dollars for marketing.  So we don't have hundreds of developers to throw
> at a project.  We have something *else* they don't have:  a bunch of
> middle-management business-as-usual MBA-drones.)

    Actually, IMHO, we have something that 'those commercial products'
don't have...a passion and a love for what we do, else we wouldn't be
doing it.  Therefore, our code *tends* to be cleaner and more stable, as a
result...

> Reliability:  You don't need me to point out that a lot of work needs to
> be done here.  These issues are tough ones to counter.  Why doesn't
> pg_dump actually preserve everything?  (It's getting better, I know, but
> it's not there right now.)

    What currently isn't being preserved?

> Why do you have to vacuum the database every
> night?

    Statistics and database cleanups.  Last I heard, there is working
being done on removing the locks imposed by vacuum for doing the
statistics, and there is talk about doing work such that 'dead space'
where deleted data resided is reused instead of sitting idle until the
next vacuum...

> Questions like that are tough to answer to people's
> satisfaction, and that's without even going into things like memory
> leaks.

    What memory leaks? :)  Actually, alot of work seems to go into
each this aspect prior to each release, so this should be getting *alot*
better...

> Crucial basics:  Views---they desperately need fixing up.  Foreign keys,
> constraints, and SQL-language triggers are critical as well.  I think
> HAVING, OUTER and INTERSECTS are being worked on.  Temporary
> tables---are those being worked on?  Yes, I know, most of these are on
> the TODO list already, but their current state of nonbeing is keenly
> felt, and hinders the cause quite a bit.

    I keep meaning to work on this, but I'm going to look into getting
PTS/Keystone installed on the server so that our TODO list can be slightly
more dynamic, where someone can claim and comment progress on the various
areas...that might help some...

> The draws:  These are the things that should be distinguishing
> PostgreSQL from the rest of the pack.  The source code is a big draw,
> but it's still hard to grok.  A concerted effort should be going on to
> document the code itself.

    Bruce has been working on this as he goes along...I don't know if
anyone else is helping him with it though...

> Breaking out built-in types into their own
> easy-to-locate files would also be good, too; I had to work to find out
> how the box functions were defined, where it would have been better to
> have a built-in-types directory with a file in there named box.c, for
> example, with the data representation and the function source all neatly
> bundled---then it would be *easy* to use that as a template to come up
> with a different type.

    Have you looked into what it would take to do such?

Marc G. Fournier
Systems Administrator @ hub.org
primary: scrappy@hub.org           secondary: scrappy@{freebsd|postgresql}.org

On Thu, 23 Jul 1998, Maarten Boekhold wrote:

> > Exactly. I'm learning SQL and PostgreSQL at the same time and it is
> > sometimes difficult for me to correctly assess what belongs with each. My
> > recent GRANT/REVOKE question was like this. I didn't think for a minute
> > that would be handled by SQL since databases were created and destroyed by
> > PostgreSQL utilities.
>
> In fact, they are handled by SQL: CREATE DATABASE and DROP DATABASE. The
> createdb and destroydb tools just call these SQL statements....

    Here's an odd thought:

    Let's remove the "I don't want to think" utilities like
{create,destroy}{db,user} and force DBA's to actually use the *proper*
functions.

Marc G. Fournier
Systems Administrator @ hub.org
primary: scrappy@hub.org           secondary: scrappy@{freebsd|postgresql}.org

scrappy@hub.org (The Hermit Hacker) writes:

| > A lot of them "look good" at first glance.  The problem seems to be that
| > the implementations tend to be spotty and incomplete amongst the
| > packages I've looked at.  None of them are robust or complete enough for
| > most commercial use.
|
| And you've, of course, discussed these failings with the authors of the
| software itself?  Or did you do like most and just drop the software as being
| incomplete?

Uh . . . I'm not slighting the authors of the software, nor am I even slighting
the software itself.  All I'm saying is that, as a consultant, I can't yet
recommend any for commercial use, and that hinders the adoption of PostgreSQL
by commercial entities.  That's all.  I didn't say *anything* about whether *I*
use them or not.  Nor did I say that the authors were unresponsive, or anything
of the sort.

| We've been going, what, 2 years now?

Hey, I freely confess that I'm feeling impatient.  :)

| [...] if everyone just writes them off, then the author's have no reason, or
| desire, to maintain them.

Which is exactly what worries me.  Businesses hire me, often looking to me to
save them money and/or time, and provide process improvement (whether that be
new applications, more reliability, whatever).  Often, a free Unix variant will
serve the purpose they're looking for---file server, print server, mail server,
web server, all stable services.  But when the question of databases comes up,
and they want something as stable and full-featured, I do something that
frustrates me:  I tell the truth.  "Outer joins?"  "No."  "Replication?"  "No."
And so on.

And that's why I get impatient.  PgSQL is *so* *close* to being something I can
say, "Look, most of the stuff you *require* in Oracle, you can have for free,
and look at some of these other features!"  But not yet.

| They label themselves an RDBMS, so I personally think that *not* including
| them would be frowned upon by those looking at the comparison as being a
| slight.

Ah.  That's a good point, and one I hadn't considered.

| Have you looked into what it would take to do such? [types in separate files]

A little.  Scares the heck outta me.  :)

                            ---Ken

The Hermit Hacker wrote:

> On Wed, 22 Jul 1998, Ken McGlothlen wrote:
>
> > Does Oracle even have a vacuum?  There's the COELESCE command, but it's hardly
> > *necessary*.
>

Nope.. Oracle has a background process which re-allocates free space..It does get
fragmented, and the only real way to unfrag is to export (dump) and import.No Vacuum,
at least on 7.3.2

--
++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
Michael - System Administrator              Working in Cheap Canadian Dollars
Unix Administration - WebSite Hosting - Network Services - Programming
Wizard Internet Services - TechnoWizard Computers - Wizard Tower TechnoServices
------------------------------------------------------------------------------
(604) 589-0037          Beautiful British Columbia, Canada
++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++

On Thu, 23 Jul 1998, The Hermit Hacker wrote:

> On Thu, 23 Jul 1998, Maarten Boekhold wrote:
>
> > > Exactly. I'm learning SQL and PostgreSQL at the same time and it is
> > > sometimes difficult for me to correctly assess what belongs with each. My
> > > recent GRANT/REVOKE question was like this. I didn't think for a minute
> > > that would be handled by SQL since databases were created and destroyed by
> > > PostgreSQL utilities.
> >
> > In fact, they are handled by SQL: CREATE DATABASE and DROP DATABASE. The
> > createdb and destroydb tools just call these SQL statements....
>
>     Here's an odd thought:
>
>     Let's remove the "I don't want to think" utilities like
> {create,destroy}{db,user} and force DBA's to actually use the *proper*
> functions.

I'm all in favour.....

Maarten

_____________________________________________________________________________
| TU Delft, The Netherlands, Faculty of Information Technology and Systems  |
|                   Department of Electrical Engineering                    |
|           Computer Architecture and Digital Technique section             |
|                          M.Boekhold@et.tudelft.nl                         |
-----------------------------------------------------------------------------

On Thu, 23 Jul 1998, The Web Administrator wrote:

> Nope.. Oracle has a background process which re-allocates free space..It does get
> fragmented, and the only real way to unfrag is to export (dump) and import.No Vacuum,
> at least on 7.3.2

    So, essentially, our VACUUM command provides functionality that
Oracle *doesn't* have, right?

Marc G. Fournier                                 marc.fournier@acadiau.ca
Systems Administrator, Acadia University

  "These are my opinions, which are not necessarily shared by my employer"