|
Home > Archive > PostgreSQL JDBC > November 2005 > Driver does not report all catalogs
You are viewing an archived Text-only version of the thread.
To view this thread in it's original format and/or if you want to reply to
this thread please [click here]
| Author |
Driver does not report all catalogs
|
|
| Martin Keller 2005-11-29, 7:24 am |
| Hi,
newer versions of the PostgreSQL JDBC driver don't return all databases
of the server when calling DatabaseMetaData.getCatalogs(...).
Can anyone tell me, why this change was neccessary? It's incompatible to
JDBC spec and brakes existing code.
Regards,
Martin
---------------------------(end of broadcast)---------------------------
TIP 2: Don't 'kill -9' the postmaster
| |
| Kris Jurka 2005-11-29, 8:25 pm |
|
On Tue, 29 Nov 2005, Martin Keller wrote:
> newer versions of the PostgreSQL JDBC driver don't return all databases of
> the server when calling DatabaseMetaData.getCatalogs(...).
> Can anyone tell me, why this change was neccessary? It's incompatible to JDBC
> spec and brakes existing code.
>
This was discussed quite some time ago, starting here:
http://archives.postgresql.org/pgsq...01/msg00154.php
The core issue is that while we can return a list of catalogs, you can't
do anything with them. Connection.setCatalog does nothing. Other
metadata methods ignore the catalog filter as well. Pretending the other
catalogs don't exist makes certain applications work better, DBVisualizer
for example. What are you using it for?
Kris Jurka
---------------------------(end of broadcast)---------------------------
TIP 1: 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
| |
| Martin Keller 2005-11-30, 3:23 am |
| We use this to show the list of available databases to the users. I
know, that this list can be retrieved with a select on pg_database, but
our application runs with various database systems and we try to avoid
database specific code. The issues with some of the metadata methods and
Connection.setCatalog don't affect the rest of our code, because the
connections are dedicated to each used database.
Martin Keller
Kris Jurka wrote:
>
>
> On Tue, 29 Nov 2005, Martin Keller wrote:
>
>
> This was discussed quite some time ago, starting here:
>
> http://archives.postgresql.org/pgsq...01/msg00154.php
>
> The core issue is that while we can return a list of catalogs, you
> can't do anything with them. Connection.setCatalog does nothing.
> Other metadata methods ignore the catalog filter as well. Pretending
> the other catalogs don't exist makes certain applications work better,
> DBVisualizer for example. What are you using it for?
>
> Kris Jurka
---------------------------(end of broadcast)---------------------------
TIP 2: Don't 'kill -9' the postmaster
| |
| Kris Jurka 2005-11-30, 3:23 am |
|
On Wed, 30 Nov 2005, Martin Keller wrote:
> We use this to show the list of available databases to the users. I know,
> that this list can be retrieved with a select on pg_database, but our
> application runs with various database systems and we try to avoid database
> specific code. The issues with some of the metadata methods and
> Connection.setCatalog don't affect the rest of our code, because the
> connections are dedicated to each used database.
>
If you don't setCatalog or use metadata, what do you do with the
database names once you've got them? Put it in a connection url?
Clearly this is a database dependent task. How do you do a login before
getting the list of databases? How do you know the given user can connect
to the given database?
This list of problems shows why I don't think it's a real good idea to
advertise the list of databases. Now I did make this change relatively
recently on a nearly two year old discussion, so I'm certainly willing to
reopen it, but you can see which side I'm leaning towards.
Kris Jurka
---------------------------(end of broadcast)---------------------------
TIP 4: Have you searched our list archives?
http://archives.postgresql.org
| |
| Kris Jurka 2005-11-30, 7:24 am |
|
On Wed, 30 Nov 2005, Martin Keller wrote:
> Yes, we are using the names for building connection urls and so far you are
> right, that this is a database dependent task. There is some user interaction
> neccessary, if user credentials differ. Our code related to this works for
> years now and most parts of it are portable, some are not.
> I understand and respect your opinion but you should consider, that changing
> driver behaviour this way is a dangerous thing. It does not meet the spec
> (the spec only says, what DatabaseMetaData.getCatalogs() has to do, but not,
> that this is dependent on the behavior of any other method) and breaks
> existing code.
>
Keeping this on list is where you are likely to find friends in this
discussion. I'd certainly like to hear from any other dissenting or
concurring opinions. Perhaps citing the list of other databases that
implement getCatalogs as you'd like would be useful. Also noting their
stance on setCatalog and metadata would help.
Naturally the Javadoc you refer to is vague, it states, "Retrieves
the catalog names available in this database." Now clearly my question is
available to what? My answer is to call setCatalog or query metadata.
Kris Jurka
---------------------------(end of broadcast)---------------------------
TIP 9: In versions below 8.0, the planner will ignore your desire to
choose an index scan if your joining column's datatypes do not
match
|
|
|
|
|