RE: Connection.setCatalog()

[[[ Original Message from Peter Eisentraut <peter_e(at)gmx(dot)net> ]]]

> jason(at)netspade(dot)com writes:
>
> > What do they mean by database though? It is vague because the
> > definitions are not clear, but I interpret it like this: A "catalog"
> > equals "PostgreSQL database" which is a subset of the whole "database"
> > assuming "database" in this context to mean the whole server. I
> > realise that the "catalog" is fixed but this is also the case for
> > MySQL. Note it doesn't say "in current connection" so no reason why
> > you can't create a new one. The bottom line is that supporting them
> > would make life easier for people like me writing a database admin
> > tool.
>
> This seems like a reasonable interpretation. Given that the alternative
> would be to not implement it at all, I would agree if you'd implement it
> as suggested.

Great, thanks. Here is a context diff against current CVS for org.postgresql.Connection.get/setCatalog() - is this the correct place to implement the methods? - the no-op methods were replicated in both jdbc1 and jdbc2 subclasses. I've made the diff remove the no-op methods in the jdbc1 and jdbc2 subclasses.

> > > > The DatabaseMetaData.supportsCatalogsInXXX() may need to be modified.
> > >
> > > These methods are all implemented correctly.
> > >
> > > > I'm not sure about the stuff in DatabaseMetaData.getTables() for
> > > > example - at the moment specifying null gets all the tables in the
> > > > database which the driver is currently connected to. I think this is
> > > > fine - but different database name patterns might be specified and
> > > > they may have to be implemented?
> > >
> > > Yup. We'll just throw an SQLException in that case.
> >
> > Yes, that isn't really a problem. But _if_ you want to support catalogs maybe
> you have to go the whole way?
>
> Do you mean that DatabaseMetaData.getTables() in a catalog other than the
> current one should reset the connection to the new catalog? That sounds a
> bit too revolutionary to me, but then again, as above, the alternative is
> to not allow it at all.

Yes. I agree that it's a bit pointless - it would make life easier for everyone if it was not allowed at all. Do you know whether PostgreSQL will support the catalogname.tablename syntax in SQL queries in the future? At the moment it seems as if catalogs are kinda half supported - you can list all catalogs on the system but you can't manipulate between them easily. For now at least I suggest we leave these methods alone.

Thanks,
Jason
>
> --
> Peter Eisentraut peter_e(at)gmx(dot)net http://funkturm.homeip.net/~peter
>