From: | Assaf Arkin <arkin(at)exoffice(dot)com> |
---|---|
To: | Peter Mount <petermount(at)it(dot)maidstone(dot)gov(dot)uk> |
Cc: | pgsql-interfaces(at)hub(dot)org, "'pgsql-hackers(at)postgresql(dot)org'" <pgsql-hackers(at)postgresql(dot)org> |
Subject: | Re: [INTERFACES] Transaction support in 6.5.3/JDBC |
Date: | 1999-12-09 18:42:43 |
Message-ID: | 384FF823.93EBC358@exoffice.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers pgsql-interfaces |
> PM: I wonder if we can get this functionality in the backend's parser -
> ie, for the API interfaces, they can set a variable on startup that
> disables begin, commit and rollback, then when they need to use them, it
> can then either temporarily clear the variable, or use a prefix that
> forces the statement to work?
>
> PM: enableSQLTransactions can then act immediately above this
> functionality.
That's what I was hoping for.
> 2. prepare -- should return false if the transaction is read-only, true
> if it will commit, throw an exception if it will rollback
Works fine now that I've added a check for *ABORT STATUS*.
> 3. isCriticalError -- should tell me if a critical error occured in the
> connection and the connection is no longer useable
>
> How do I detect no. 3? Is there are certain range of error codes, should
> I just look at certain PSQLExceptions as being critial (e.g. all I/O
> related errors)?
>
> PM: Don't rely on the text returned from PSQLException to be in English.
> We are pretty unique in that the driver will return an error message in
> the language defined by the locale of the client (also depends on if we
> have translated the errors into that language). What I could to is add a
> method to PSQLException that returns the original id of the Exception,
> and another to return the arguments supplied. That may make your code
> more portable.
I'm not looking into the messages, I know their language dependent. I
even added two or three new error messages, but only in English.
I'm looking for either specific error codes, range of error codes, or
some class extending PSQLException that will just indicate that this
connection is no longer useful. For example, if an I/O error occurs,
there's no ReadyForQuery reply, there's garbled response, etc.
arkin
>
> Peter
>
> --
> Peter Mount
> Enterprise Support
> Maidstone Borough Council
> Any views stated are my own, and not those of Maidstone Borough Council.
>
> ************
--
____________________________________________________________
Assaf Arkin arkin(at)exoffice(dot)com
CTO http://www.exoffice.com
Exoffice, The ExoLab Company tel: (650) 259-9796
From | Date | Subject | |
---|---|---|---|
Next Message | Jan Wieck | 1999-12-09 19:43:17 | Weired FK problem |
Previous Message | Don Baccus | 1999-12-09 16:00:50 | check contraints incorrectly reject "null" |
From | Date | Subject | |
---|---|---|---|
Next Message | Adolfo Diaz | 1999-12-09 20:14:57 | Apache+PostgreSQL+PHP3 |
Previous Message | Assaf Arkin | 1999-12-09 18:14:16 | Re: [INTERFACES] Transaction support in 6.5.3/JDBC |