469,636 Members | 1,929 Online
Bytes | Developer Community
New Post

Home Posts Topics Members FAQ

Post your question to a community of 469,636 developers. It's quick & easy.

Migrating from MaxDB to postgresql

As per subject, i'm considering migrating a database (still in
development) from MaxDB to postgresql. The main reason for this is that
the stored procedures (functions) in MaxDB are unreliable and hard to
debug, and that the JDBC driver is still experimental.

I thought I'd post here to find out how well functions and JDBC are
supported in postgresql.

If anyone has info or experience on these two things, I'd be interested
to see what your opinion is.

John
Nov 23 '05 #1
2 1544
Quoth John <no@email>:
As per subject, i'm considering migrating a database (still in
development) from MaxDB to postgresql. The main reason for this is
that the stored procedures (functions) in MaxDB are unreliable and
hard to debug, and that the JDBC driver is still experimental.

I thought I'd post here to find out how well functions and JDBC are
supported in postgresql.

If anyone has info or experience on these two things, I'd be
interested to see what your opinion is.


Some internal "hackery" has occasionally taken place with JDBC drivers
that have caused internal consternation (basically due to developers
needing some new features that were in the "beta" JDBC code), although
that seems to be fading with 7.4. And if you don't hack on the
drivers, you won't get bitten by that sort of thing :-).

The fact that there are easily multiple levels of quoting in stored
functions certainly makes debugging a bit of a pain, but unreliability
is not one of the problems observed. For instance, the Slony-I
replication system <http://slony.info/> has a considerable portion of
its code that consists of pl/pgsql stored functions, and it would
break with great horribleness if stored functions were at all
"flakey."
--
"cbbrowne","@","linuxfinances.info"
http://www.ntlug.org/~cbbrowne/
Just because you're paranoid doesn't mean they AREN'T after you.
Nov 23 '05 #2
Christopher Browne wrote:
Quoth John <no@email>:
As per subject, i'm considering migrating a database (still in
development) from MaxDB to postgresql. The main reason for this is
that the stored procedures (functions) in MaxDB are unreliable and
hard to debug, and that the JDBC driver is still experimental.

I thought I'd post here to find out how well functions and JDBC are
supported in postgresql.

If anyone has info or experience on these two things, I'd be
interested to see what your opinion is.

Some internal "hackery" has occasionally taken place with JDBC drivers
that have caused internal consternation (basically due to developers
needing some new features that were in the "beta" JDBC code), although
that seems to be fading with 7.4. And if you don't hack on the
drivers, you won't get bitten by that sort of thing :-).

The fact that there are easily multiple levels of quoting in stored
functions certainly makes debugging a bit of a pain, but unreliability
is not one of the problems observed. For instance, the Slony-I
replication system <http://slony.info/> has a considerable portion of
its code that consists of pl/pgsql stored functions, and it would
break with great horribleness if stored functions were at all
"flakey."


Cheers Christopher.

I'll try and resist the hackage and get started with the JDBC. The
quality of the documentation seems good, so I'll have a go at
translating some stored functions this afternoon.

John
Nov 23 '05 #3

This discussion thread is closed

Replies have been disabled for this discussion.

Similar topics

2 posts views Thread by dan | last post: by
reply views Thread by Danny | last post: by
1 post views Thread by Steve Malley | last post: by
reply views Thread by Matthias M. | last post: by
4 posts views Thread by Bernardo Robelo | last post: by
5 posts views Thread by Larry Menard | last post: by
2 posts views Thread by Jean-Claude Adams | last post: by
reply views Thread by gheharukoh7 | last post: by
By using this site, you agree to our Privacy Policy and Terms of Use.