Re: [JDBC] Connection.setCatalog()
Patch applied. Thanks. [[[ Original Message from Tom Lane [EMAIL PROTECTED] ]]] Peter Eisentraut [EMAIL PROTECTED] writes: Tom Lane writes: Peter E. has previously commented that Postgres databases correspond most closely to the SQL concept of catalog cluster, not catalog. I most certainly did not. According to my interpretation: I sit corrected. If you want to define catalog == database, okay with me. regards, tom lane Great, here is a context diff of CVS for implementing the get/setCatalog methods in Connection - note: I've updated setCatalog(String catalog) from my previous diff so it checks whether it is already connected to the specified catalog. Thanks, Jason Davies [EMAIL PROTECTED] [ Attachment, skipping... ] ---(end of broadcast)--- TIP 5: Have you checked our extensive FAQ? http://www.postgresql.org/users-lounge/docs/faq.html -- Bruce Momjian| http://candle.pha.pa.us [EMAIL PROTECTED] | (610) 853-3000 + If your life is a hard drive, | 830 Blythe Avenue + Christ can be your backup.| Drexel Hill, Pennsylvania 19026 ---(end of broadcast)--- TIP 6: Have you searched our list archives? http://www.postgresql.org/search.mpl
Re: [JDBC] Connection.setCatalog()
OK, seems like this is the final one to be applied. Your patch has been added to the PostgreSQL unapplied patches list at: http://candle.pha.pa.us/cgi-bin/pgpatches I will try to apply it within the next 48 hours. [[[ Original Message from Tom Lane [EMAIL PROTECTED] ]]] Peter Eisentraut [EMAIL PROTECTED] writes: Tom Lane writes: Peter E. has previously commented that Postgres databases correspond most closely to the SQL concept of catalog cluster, not catalog. I most certainly did not. According to my interpretation: I sit corrected. If you want to define catalog == database, okay with me. regards, tom lane Great, here is a context diff of CVS for implementing the get/setCatalog methods in Connection - note: I've updated setCatalog(String catalog) from my previous diff so it checks whether it is already connected to the specified catalog. Thanks, Jason Davies [EMAIL PROTECTED] [ Attachment, skipping... ] ---(end of broadcast)--- TIP 5: Have you checked our extensive FAQ? http://www.postgresql.org/users-lounge/docs/faq.html -- Bruce Momjian| http://candle.pha.pa.us [EMAIL PROTECTED] | (610) 853-3000 + If your life is a hard drive, | 830 Blythe Avenue + Christ can be your backup.| Drexel Hill, Pennsylvania 19026 ---(end of broadcast)--- TIP 1: subscribe and unsubscribe commands go to [EMAIL PROTECTED]
Re: [JDBC] Connection.setCatalog()
[[[ Original Message from Tom Lane [EMAIL PROTECTED] ]]] Peter Eisentraut [EMAIL PROTECTED] writes: Tom Lane writes: Peter E. has previously commented that Postgres databases correspond most closely to the SQL concept of catalog cluster, not catalog. I most certainly did not. According to my interpretation: I sit corrected. If you want to define catalog == database, okay with me. regards, tom lane Great, here is a context diff of CVS for implementing the get/setCatalog methods in Connection - note: I've updated setCatalog(String catalog) from my previous diff so it checks whether it is already connected to the specified catalog. Thanks, Jason Davies [EMAIL PROTECTED] Connection.diff ---(end of broadcast)--- TIP 5: Have you checked our extensive FAQ? http://www.postgresql.org/users-lounge/docs/faq.html
Re: [JDBC] Connection.setCatalog()
Peter Eisentraut [EMAIL PROTECTED] writes: Tom Lane writes: Peter E. has previously commented that Postgres databases correspond most closely to the SQL concept of catalog cluster, not catalog. I most certainly did not. According to my interpretation: I sit corrected. If you want to define catalog == database, okay with me. regards, tom lane ---(end of broadcast)--- TIP 3: if posting/reading through Usenet, please send an appropriate subscribe-nomail command to [EMAIL PROTECTED] so that your message can get through to the mailing list cleanly
Re: [JDBC] Connection.setCatalog()
Tom Lane writes: Peter E. has previously commented that Postgres databases correspond most closely to the SQL concept of catalog cluster, not catalog. I most certainly did not. According to my interpretation: schema = schema catalog = database cluster = thing you get from initdb This is also how we currently document it and it tends to be the practice in other products as well. This agrees with my reading of SQL92 4.13: A cluster is an implementation-defined collection of catalogs. Exactly one cluster is associated with an SQL-session and it defines the totality of the SQL-data that is available to that SQL-session. Yes, the stuff served by a single postmaster is the totality of the SQL data available to that SQL session. But note: The method of creation and destruction of catalogs is implementation-defined. The set of catalogs that can be referenced in any SQL-statement, during any particular SQL-transaction, or during the course of an SQL-session is also implementation-defined. (just above your stuff) which serves us just fine. -- Peter Eisentraut [EMAIL PROTECTED] http://funkturm.homeip.net/~peter ---(end of broadcast)--- TIP 1: subscribe and unsubscribe commands go to [EMAIL PROTECTED]
Re: [JDBC] Connection.setCatalog()
[[[ Original Message from Tom Lane [EMAIL PROTECTED] ]]] [EMAIL PROTECTED] writes: Do you know whether PostgreSQL will support the catalogname.tablename syntax in SQL queries in the future? Schema support is on the to-do list. It's probably too late to imagine that it will get done for 7.2, but maybe for 7.3. Although the details haven't been argued out yet, I suspect that the existing concept of independent databases within an installation will remain in place (for backwards compatibility if nothing else). SQL-style schemas and catalogs will exist as new naming levels *within* what we now call a database. I see - I didn't realise this. As this is the case, there is no need for my database tool to list available databases since databases in postgresql are clusters. Thanks for clarifying that. Peter E. has previously commented that Postgres databases correspond most closely to the SQL concept of catalog cluster, not catalog. This agrees with my reading of SQL92 4.13: A cluster is an implementation-defined collection of catalogs. Exactly one cluster is associated with an SQL-session and it defines the totality of the SQL-data that is available to that SQL-session. Schemas and catalogs will exist within a database, and there will still be no possibility of cross-database accesses (but, hopefully, much less need for it either). Good. As long as everything conforms to some kind of standard we're okay :) While I haven't followed this discussion closely, it appears to me that you are trying to make setCatalog reconnect to a new database --- ie, a new cluster in SQL terminology. I think this is a bad idea, as it will create a backwards compatibility problem once we have actual catalogs for setCatalog to work with. I'd suggest that the right short-term thing is for setCatalog to either do nothing or throw an error. I agree. In which case the update Peter E did to DatabaseMetaData.getCatalogs() should be backed out. At least I've learnt how to use CVS and how to make context diffs :) regards, tom lane Jason Davies [EMAIL PROTECTED] ---(end of broadcast)--- TIP 4: Don't 'kill -9' the postmaster
RE: [JDBC] Connection.setCatalog()
[[[ Original Message from Peter Eisentraut [EMAIL PROTECTED] ]]] [EMAIL PROTECTED] 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 [EMAIL PROTECTED] http://funkturm.homeip.net/~peter Connection.diff ---(end of broadcast)--- TIP 4: Don't 'kill -9' the postmaster
RE: [JDBC] Connection.setCatalog()
[EMAIL PROTECTED] 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. 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. -- Peter Eisentraut [EMAIL PROTECTED] http://funkturm.homeip.net/~peter ---(end of broadcast)--- TIP 4: Don't 'kill -9' the postmaster
