[Fwd: Re: Connection.setCatalog method] - Mailing list pgsql-jdbc
From | Philip A. Chapman |
---|---|
Subject | [Fwd: Re: Connection.setCatalog method] |
Date | |
Msg-id | 1060121218.9509.60.camel@dragon.acoeis.com Whole thread Raw |
List | pgsql-jdbc |
Forgot to CC in the list. Sorry list users. -----Forwarded Message----- From: Philip A. Chapman <pchapman@pcsw.us> To: Barry Lind <blind@xythos.com> Subject: Re: [JDBC] Connection.setCatalog method Date: 05 Aug 2003 17:02:06 -0500 Barry, I find your arguments reasonable enough. I will try to determine if there is a better way to write the setConnection() method. I suggest that a SQLException be thrown in the event that a) A transaction is in process or b) The user does not have authority to connect to the other database. If I can engineer a more acceptable setConnection() method, I will send it to you. Otherwise, if Connection.setCatalog() can not be implemented because Database != Catalog, then I suggest that Connection.getCatalog() and DatabaseMetaData.getCatalogs() should not be implemented as well. I find myself not arguing for implementation so much as consistancy. Thanks for your time, On Tue, 2003-08-05 at 16:34, Barry Lind wrote: > That patch wasn't applied because I vetoed it. I am unhappy with the > logic as it appeared in that patch, but due to the limitations of the > server I don't know of anyway to implement setCatalog(). > > There are two problems I have with the patch as it was originally submitted: > > 1) Transaction problems. Lets say I am in the middle of a transaction > when I call setCatalog(), since the implementation simply closes the > current connection and opens a new one, my in process transaction is > aborted. Which is certainly against the spec. In general, I don't like > the patch because is under the covers replaces the existing connection > with a new one that can have a whole slew of side effects that are not > addressed (what happens to existing statement objects? existing result > sets? existing database meta data objects?). > > 2) The patch makes the invalid assumption that just because the current > username/password lets me connect to database A, it will also let me > connect to database B. Thus calling setCatalog() if you have security > setup will leave your connection hosed. > > Finally while it may seem on the surface that postgresql databases are > the same thing as jdbc catalogs, there are many differences. Enough > that in my opinion they should not be considered the same thing. For > example: > > DatabaseMetaData.isCatalogAtStart() says: > * Retrieves whether a catalog appears at the start of a fully qualified > * table name. If not, the catalog appears at the end. > Thus the jdbc concept of catalog also is a namespace concept (ala > database.schema.table which postgres doesn't support). > > DatabaseMetaData.get*() methods that take a catalog parameter: > All of these methods assume that you can get information from any > catalog/database. But in postgres that isn't true. You can only get > meta information for the database you are currently connected to. And > because of the issue #2 above there really isn't any way to get > information about other databases objects. > > > Now I am certainly not against enhanceing postgres to support the jdbc > view of catalogs, but I think it is much more work and likely will need > to be done very differently than the below mentioned patch does things. > > thanks, > --Barry > > > > Fernando Nasser wrote: > > Yes, setCatalog() should switch the connection to another database (it > > can only be ignored if the driver does not support catalogs, which is > > not the case). > > > > I have no idea why that patch was not applied. Could not find anything > > after the thread you've pointed to. > > > > Regards, > > Fernando > > > > > > Philip A. Chapman wrote: > > > >> Everyone, > >> > >> I am working on yet another database administration application. I have > >> run into some issues because the JDBC implementation of > >> Connection.setCatalog() > >> (org.postgresq.jdbc1.AbstractJdbc1Connection.java) does nothing when > >> setCatalog() is called. My understanding is that doing nothing is > >> allowed by the JDBC specification, but this is somewhat confusing as > >> getCatalog() returns a value and DatabaseMetaData.getCatalogs() returns > >> a list of values. > >> > >> While searching though this list's archives, I found a thread from July > >> of 2001 that deals with this subject. Toward the end of the thread, it > >> appears as though it was decided that the setCatalog() functionallity > >> should be implemented and that a patch was to be accepted to make this > >> happen: > >> > >> http://archives.postgresql.org/pgsql-jdbc/2001-07/msg00150.php > >> > >> What has become of this? Can someone shed some light on why > >> Connection.getCatalog and DatabaseMetaData.getCatalogs() work, but > >> Connection.setCatalog does not? > > > > > > -- Philip A. Chapman Application Development: Java, Visual Basic (MCP), PostgreSQL, MySQL, MSSQL Linux, Windows 9x, Windows NT, Windows 2000, Windows XP -- Philip A. Chapman Application Development: Java, Visual Basic (MCP), PostgreSQL, MySQL, MSSQL Linux, Windows 9x, Windows NT, Windows 2000, Windows XP
Attachment
pgsql-jdbc by date: