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

I couldn't agree with you more.  I'm just a developer in a very large
company and getting anyone to listen and then understand that logic would
be a nightmare to say the least.  If it was my company I would put money
toward those issues.






                           
                      Robert Treat
                           
                      <xzilla@users.sourc        To:       Bob.Henkel@hartfordlife.com, pgsql-general@postgresql.org
                           
                      eforge.net>                cc:
                           
                                                 Subject:  Re: [GENERAL] what we need to use postgresql in the
enterprise                          
                      01/12/2004 12:45 AM
                           

                           

                           




I think your pretty much on target with the below. It is possible to work
around these issues on some level, but I can see how that might get
unwieldly
in a hurry.  While I won't tell you to "go code it if you need it", I might

ask that you consider what your paying in Oracle licenses and think about
spending that money to hire someone to develop those features in
PostgreSQL,
I'm thinking you'd save money in the long run.

Robert Treat

On Friday 09 January 2004 14:48, Bob.Henkel@hartfordlife.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.
>
> 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@postgresql.org

--
Build A Brighter Lamp :: Linux Apache {middleware} PostgreSQL







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