472,139 Members | 1,680 Online
Bytes | Software Development & Data Engineering Community
Post +

Home Posts Topics Members FAQ

Join Bytes to post your question to a community of 472,139 software developers and data experts.

what we need to use postgresql in the enterprise

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 ma*******@postgresql.org

Nov 12 '05 #1
3 2489
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, Bo********@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 ma*******@postgresql.org


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

---------------------------(end of broadcast)---------------------------
TIP 6: Have you searched our list archives?

http://archives.postgresql.org

Nov 12 '05 #2
Clinging to sanity, xz****@users.sourceforge.net (Robert Treat) mumbled into her beard:
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.


I was under the impression that someone was working on nested
transactions, with a view of them maybe becoming a 7.5 feature.

It might thereby be worthwhile to figure out who that "someone" is,
which is probably googleable, and maybe offer them something of a
"bounty," whereby if the feature makes it in, there might be some
money in it...
--
output = ("cbbrowne" "@" "acm.org")
http://cbbrowne.com/info/spreadsheets.html
This login session: only $23.95!
Nov 12 '05 #3
--- Bo********@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.
#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

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

---------------------------(end of broadcast)---------------------------
TIP 6: Have you searched our list archives?

http://archives.postgresql.org

Nov 12 '05 #4

This discussion thread is closed

Replies have been disabled for this discussion.

Similar topics

5 posts views Thread by google account | last post: by
236 posts views Thread by Andrew Rawnsley | last post: by
59 posts views Thread by Jeff Bowden | last post: by
1 post views Thread by John Wells | last post: by

By using Bytes.com and it's services, you agree to our Privacy Policy and Terms of Use.

To disable or enable advertisements and analytics tracking please visit the manage ads & tracking page.