Hi Richard, Thanks for your comments.
I can see where you are coming from but I am not sure if a new log entry would be such a good idea. The result of creating such a low level log could be to increase the amount of logging by a rather large amount. However, the system catalogue will contain an entry that enables a cursor to be identified as updatable. Regards, John Bartlett Software Development Engineer Fujitsu Australia Software Technology 14 Rodborough Road, Frenchs Forest NSW 2086 Tel: +61 2 9452 9161 Fax: +61 2 9975 2899 Email: [EMAIL PROTECTED] Web site: www.fastware.com -----Original Message----- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Richard Troy Sent: Wednesday, 24 January 2007 4:37 AM To: FAST PostgreSQL Cc: PostgreSQL-development Subject: Re: [HACKERS] Updateable cursors On Wed, 24 Jan 2007, FAST PostgreSQL wrote: > > We are trying to develop the updateable cursors functionality into > Postgresql. I have given below details of the design and also issues we are > facing. Looking forward to the advice on how to proceed with these issues. > > Rgds, > Arul Shaji > Hi Arul, ...I can see people are picking apart the implementation details so you're getting good feedback on your ambitious proposal. Looks like you've put a lot of thought/work into it. I've never been a fan of cursors because they encourage bad behavior; "Think time" in a transaction sometimes becomes "lunch time" for users and in any event long lock duration is something to be avoided for the sake of concurrency and sometimes performance (vacuum, etc). My philosophy is "get in and get out quick." Ten years ago May, our first customer insisted we implement what has become our primary API library in Java and somewhat later I was shocked to learn that for whatever reason Java ResultSets are supposed to be implemented as _updateable_cursors._ This created serious security issues for handing off results to other programs through the library - ones that don't even have the ability to connect to the target database. Confirmed in the behavior of Informix, we went through some hoops to remove the need to pass ResultSets around. (If I had only known Postgres didn't implement the RS as an updateable cursor, I'd have pushed for our primary platform to be Postgres!) What impresses me is that Postgres has survived so well without updateable cursors. To my mind it illustrates that they aren't widely used. I'm wondering what troubles lurk ahead once they're available. As a DBA/SysAdmin, I'd be quite happy that there existed some kind of log element that indicated updateable cursors were in use that I could search for easily whenever trying to diagnose some performance or deadlocking problem, etc, say log fiile entries that indicated the opening and later closing of such a cursor with an id of some kind that allowed matching up open/close pairs. I also think that that the documentation should be updated to not only indicate usage of this new feature, but provide cautionary warnings about the potential locking issues and, for the authors of libraries, Java in particular, the possible security issues. Regards, Richard -- Richard Troy, Chief Scientist Science Tools Corporation 510-924-1363 or 202-747-1263 [EMAIL PROTECTED], http://ScienceTools.com/ ---------------------------(end of broadcast)--------------------------- TIP 1: if posting/reading through Usenet, please send an appropriate subscribe-nomail command to [EMAIL PROTECTED] so that your message can get through to the mailing list cleanly This is an email from Fujitsu Australia Software Technology Pty Ltd, ABN 27 003 693 481. It is confidential to the ordinary user of the email address to which it was addressed and may contain copyright and/or legally privileged information. No one else may read, print, store, copy or forward all or any of it or its attachments. If you receive this email in error, please return to sender. Thank you. If you do not wish to receive commercial email messages from Fujitsu Australia Software Technology Pty Ltd, please email [EMAIL PROTECTED] ---------------------------(end of broadcast)--------------------------- TIP 1: if posting/reading through Usenet, please send an appropriate subscribe-nomail command to [EMAIL PROTECTED] so that your message can get through to the mailing list cleanly
