Thread: extended error codes in the JDBC driver
What would it take to get meaningful extended error code reporting into a more useful state? My company is looking at using PostgreSQL for a commercial deployment and this seems to be a big roadblock to using PostgreSQL's JDBC driver. Is there a company that could be contracted to provide this feature? Is this too large a task to do in a relatively short amount of time? Just curious since I've been prodded to make a few inquiries on the subject. Thanks, Matthew H. Ray
Matthew, I will look into this for you. I think it may require work on the backend to get more meaningful error reporting Dave On Wed, 2002-05-08 at 19:08, mray@360commerce.com wrote: > > > What would it take to get meaningful extended error code reporting into a more > useful state? My company is looking at using PostgreSQL for a commercial > deployment and this seems to be a big roadblock to using PostgreSQL's JDBC > driver. Is there a company that could be contracted to provide this feature? > Is this too large a task to do in a relatively short amount of time? Just > curious since I've been prodded to make a few inquiries on the subject. > > Thanks, > Matthew H. Ray > > > > ---------------------------(end of broadcast)--------------------------- > TIP 4: Don't 'kill -9' the postmaster > >
Could you please define what you mean by 'extended error code reporting'? --Barry mray@360commerce.com wrote: > > What would it take to get meaningful extended error code reporting into a more > useful state? My company is looking at using PostgreSQL for a commercial > deployment and this seems to be a big roadblock to using PostgreSQL's JDBC > driver. Is there a company that could be contracted to provide this feature? > Is this too large a task to do in a relatively short amount of time? Just > curious since I've been prodded to make a few inquiries on the subject. > > Thanks, > Matthew H. Ray > > > > ---------------------------(end of broadcast)--------------------------- > TIP 4: Don't 'kill -9' the postmaster >
----- Original Message -----
From: "Barry Lind"
> Could you please define what you mean by 'extended error code reporting'?
>
I guess an error code <> 0, which will be a problem since it's related to
the backend, not the jdbc driver
best,
Marin
----
"...what you brought from your past, is of no use in your present. When
you must choose a new path, do not bring old experiences with you.
Those who strike out afresh, but who attempt to retain a little of the
old life, end up torn apart by their own memories. "
Fairly long-standing request this one, to get errno() or something similar to report an error code back to the client interfaces. I agree, its critically important because you can't determine things in the (fe) code based on parsing an error message (wellyou can, but its stupid to rely on this). It does require changes in the backend, and I guess probably not insignificant,as anywhere it previously threw an error the code'd need to be changed to use an integer constant or similar,plus creating all the error codes etc (well maybe just editing one function call ;). Still, the only driver I'veused that behaved well in this fashion was the Oracle one, and it made a really nice difference to developing. Regards, Joe > -----Original Message----- > From: pgsql-jdbc-owner@postgresql.org > [mailto:pgsql-jdbc-owner@postgresql.org]On Behalf Of Marin Dimitrov > Sent: Friday, 10 May 2002 3:01 > Cc: pgsql-jdbc@postgresql.org > Subject: Re: [JDBC] extended error codes in the JDBC driver > > > > ----- Original Message ----- > From: "Barry Lind" > > > Could you please define what you mean by 'extended error code > reporting'? > > > > I guess an error code <> 0, which will be a problem since it's related to > the backend, not the jdbc driver > > best, > > Marin > > ---- > "...what you brought from your past, is of no use in your present. When > you must choose a new path, do not bring old experiences with you. > Those who strike out afresh, but who attempt to retain a little of the > old life, end up torn apart by their own memories. " > > > > > ---------------------------(end of broadcast)--------------------------- > TIP 2: you can get off all lists at once with the unregister command > (send "unregister YourEmailAddressHere" to majordomo@postgresql.org) >
I've used mySQL before and it handled error codes. Much more convenient and reliable then parsing string errors/exceptions. Tim Lucia > -----Original Message----- > From: Joe Shevland [mailto:jshevland@j-elite.com] > Sent: Thursday, May 09, 2002 7:38 PM > To: Marin Dimitrov > Cc: pgsql-jdbc@postgresql.org > Subject: Re: [JDBC] extended error codes in the JDBC driver > > > Fairly long-standing request this one, to get errno() or > something similar to report an error code back to the client > interfaces. > > I agree, its critically important because you can't determine > things in the (fe) code based on parsing an error message > (well you can, but its stupid to rely on this). It does > require changes in the backend, and I guess probably not > insignificant, as anywhere it previously threw an error the > code'd need to be changed to use an integer constant or > similar, plus creating all the error codes etc (well maybe > just editing one function call ;). Still, the only driver > I've used that behaved well in this fashion was the Oracle > one, and it made a really nice difference to developing. > > Regards, > Joe > > > -----Original Message----- > > From: pgsql-jdbc-owner@postgresql.org > > [mailto:pgsql-jdbc-owner@postgresql.org]On Behalf Of Marin Dimitrov > > Sent: Friday, 10 May 2002 3:01 > > Cc: pgsql-jdbc@postgresql.org > > Subject: Re: [JDBC] extended error codes in the JDBC driver > > > > > > > > ----- Original Message ----- > > From: "Barry Lind" > > > > > Could you please define what you mean by 'extended error code > > reporting'? > > > > > > > I guess an error code <> 0, which will be a problem since > it's related to > > the backend, not the jdbc driver > > > > best, > > > > Marin > > > > ---- > > "...what you brought from your past, is of no use in your > present. When > > you must choose a new path, do not bring old experiences with you. > > Those who strike out afresh, but who attempt to retain a > little of the > > old life, end up torn apart by their own memories. " > > > > > > > > > > ---------------------------(end of > broadcast)--------------------------- > > TIP 2: you can get off all lists at once with the unregister command > > (send "unregister YourEmailAddressHere" to > majordomo@postgresql.org) > > > > > ---------------------------(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 >