Обсуждение: callable statements, latest snapshot
The last I heard, CallableStatements were going to be part of the 7.1 release. I downloaded the latest 7.1 snapshot (March 10th's) and was surprised to find that the Connection objects for both JDBC1 and JDBC2 drivers are hardcoded to throw an error when CallableStatements are attempted. Does this mean that CallableStatements will not be in 7.1? My project is leaning heavily on CallableStatements and I have a deadline looming, so I'd appreciate an answer on this if possible. Thanks a lot.
At 19:46 11/03/01 -0500, Gregory Bittar wrote: >The last I heard, CallableStatements were going to be >part of the 7.1 release. I downloaded the latest 7.1 >snapshot (March 10th's) and was surprised to find that >the Connection objects for both JDBC1 and JDBC2 drivers >are hardcoded to throw an error when CallableStatements >are attempted. Does this mean that CallableStatements >will not be in 7.1? That was the idea back when 7.0 was done, but with one thing or another it's got delayed. There is a group of students working on it as a class project but that won't be done until 7.2 (probably). >My project is leaning heavily on CallableStatements and >I have a deadline looming, so I'd appreciate an answer >on this if possible. Thanks a lot. > > >---------------------------(end of broadcast)--------------------------- >TIP 3: if posting/reading through Usenet, please send an appropriate >subscribe-nomail command to majordomo@postgresql.org so that your >message can get through to the mailing list cleanly
Thanks for your really timely response. It is appreciated. Forging ahead, are there any workarounds for this process? I was thinking about reorganizing things around log/event tables. An insert to a log table would trigger my stored procs, which would in turn apply more complicated business rules and SQL updates to my regular domain tables. This keeps the cost of database interaction down to one connection. I can't seem to figure out a way to return an integer code though. I could insert the return code in the log table record and then do a subsequent select to find the result. I'd have to tag the log table record with some unique value to make sure I retrieve the correct record/return code value. Is this the best that I can hope for? I want to thank you btw. All I can say is that the whole effort is very much appreciated by programmers like me who can afford to go commercial with an affordable, professional quality database. Peter Mount wrote: > That was the idea back when 7.0 was done, but with one thing or another > it's got delayed. There is a group of students working on it as a class > project but that won't be done until 7.2 (probably).