Re: what we need to use postgresql in the enterprise

--- Bob(dot)Henkel(at)hartfordlife(dot)com wrote:
> 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.

#1 & #3 both refer to the same thing, i.e. nested
transactions. Alvaro Herrera has been working on this
for some time, and recently stated on (I think) the
pgsql-hackers list that he intended to have nested
transactions ready for the next release of PostgreSQL.
On the other hand, Tom Lane recently responded to a
question about nested transactions by warning about
the complexity of the problems needing to be overcome
to make that happen, and expressing doubt about an
early solution. So you could say that the status is
unclear. A question on the -hackers list would
probably get more information.

Agreed that Oracle-style exception handling in
pl/pgsql would be a good thing. If I understand
things correctly, the new error codes scheme in
PostgreSQL version 7.4 makes that easier to implement
than before. But I am not aware of anyone working on
it.

*** Note To Developers ***
Adding Oracle-style exception handling to pl/pgsql
would greatly ease the migration path from Oracle to
PostgreSQL, and could easily result in many more
instances of Postgres being used for enterprise apps
that are now using Oracle. But I'm not up to the
task, so I'm flagging it here for anyone else who
might want to take a crack at it.

>
> 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 contain proprietary, 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,
> please notify the sender immediately by return
> e-mail, delete this communication and destroy all
> copies.
>
*************************************************************************
>
>
> ---------------------------(end of
> broadcast)---------------------------
> TIP 1: subscribe and unsubscribe commands go to
majordomo(at)postgresql(dot)org

__________________________________
Do you Yahoo!?
Yahoo! Hotjobs: Enter the "Signing Bonus" Sweepstakes
http://hotjobs.sweepstakes.yahoo.com/signingbonus