[Fwd: Re: Connection.setCatalog method]

From: "Philip A(dot) Chapman" <pchapman(at)pcsw(dot)us>
To: pgsql-jdbc(at)postgresql(dot)org
Subject: [Fwd: Re: Connection.setCatalog method]
Date: 2003-08-05 22:06:59
Message-ID: 1060121218.9509.60.camel@dragon.acoeis.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-jdbc

Forgot to CC in the list. Sorry list users.

-----Forwarded Message-----

From: Philip A. Chapman <pchapman(at)pcsw(dot)us>
To: Barry Lind <blind(at)xythos(dot)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

Browse pgsql-jdbc by date

  From Date Subject
Next Message Dave Tenny 2003-08-05 22:35:32 PostgreSQL JDBC driver Connection.setTransactionIsolation(Connection.TRANSACTION_SERIALIZABLE) failures
Previous Message Fernando Nasser 2003-08-05 21:55:03 Re: Connection.setCatalog method