what we need to use postgresql in the enterprise - Mailing list pgsql-general

From Bob.Henkel@hartfordlife.com
Subject what we need to use postgresql in the enterprise
Date
Msg-id OFBA21C953.B271BF89-ON86256E16.006B1B2A@hartfordlife.com
Whole thread Raw
Responses Re: what we need to use postgresql in the enterprise  (Robert Treat <xzilla@users.sourceforge.net>)
Re: what we need to use postgresql in the enterprise  (Jeff Eckermann <jeff_eckermann@yahoo.com>)
List pgsql-general
I write this to tell you why we won't use postgresql even though we wish we
could at a large company.  Don't get me wrong I love postgresql in many
ways and for many reasons , but fact is fact.  If you need more detail I
can be glad to prove all my points.  Our goal is to make logical systems.
We don't want php,perl, or c++ making all the procedure calls and having
the host language to be checking for errors and handleing all the
transactions commits and rollbacks.  That is not very logical in a large
batch system.  Also please don't tell me to code the changes myself.  I'm
not at that part of the food chain.  That is to low level for me and I
don't have the time to put that hat on.  I build the applications that use
the database systems.  Also please feel free to correct me in any area I
don't know everything I'm just stating my opinion here

1.  Need commit roll back in pl/pgsql much like Oracle does
2.  Need exception handling in pl/pgsql must like Oracle does
3.  A>Need sub transactions .  B>And if an inner transactions fails it
should not cause all others to fail.  If #2 was robust enough than #3 B
might not be an issue.

With those two things I could accomplish pretty much everything with
postgresql that we're currently doing in Oracle.

1. It's a must if you have long running complicated and time consuming
batch processing.  There is no reason why one should say do all of commit
and rollbacks from the client. Our current batch system gets fired off by
running some sql scripts that start an entry point into the batch system.
Once the first stored procedure is called it will call all the rest.  This
encapsulates all logic and processing in the database where it belongs.
There is no client traffic because once that first script kicks off there
is no outside process running , just our pl/sql.  Now I'm not a postgresql
expert at all but when I read up on it looks like this is something you
can't accomplish and I see no word of this being worked on.

2. Without this you can't trust complicated code as far as I'm concerned. I
need to log some errors and continue processing and for others log and exit
which I think you can do now in pl/pgsql.  Point being pl/pgsql exception
handling is almost nonexistent at best.

3. We use this all the time in pl/sql and we need to. To write this off as
not need is wrong and will not get postgresql to where it can be(AT THE
TOP).






*************************************************************************
PRIVILEGED AND CONFIDENTIAL: This communication, including attachments, is for the exclusive use of addressee and may
containproprietary, confidential and/or privileged information.  If you are not the intended recipient, any use,
copying,disclosure, dissemination or distribution is strictly prohibited.  If you are not the intended recipient,
pleasenotify the sender immediately by return e-mail, delete this communication and destroy all copies. 
*************************************************************************


pgsql-general by date:

Previous
From: "Rick Gigger"
Date:
Subject: how do I get the primary key
Next
From: Kragen Sitaker
Date:
Subject: ERROR: Cannot insert a duplicate key into unique index pg_class_relname_nsp_index