Re: Missing functionality in ResultSetMetaData ?
От | Thomas Dudziak |
---|---|
Тема | Re: Missing functionality in ResultSetMetaData ? |
Дата | |
Msg-id | 224f3234050809153725fb91c@mail.gmail.com обсуждение исходный текст |
Ответ на | Re: Missing functionality in ResultSetMetaData ? (Kris Jurka <books@ejurka.com>) |
Ответы |
Re: Missing functionality in ResultSetMetaData ?
(Kris Jurka <books@ejurka.com>)
Re: Missing functionality in ResultSetMetaData ? (Oliver Jowett <oliver@opencloud.com>) |
Список | pgsql-jdbc |
On 8/10/05, Kris Jurka <books@ejurka.com> wrote: > > > On Tue, 9 Aug 2005, Thomas Dudziak wrote: > > > Ok, thanks, I see. However, from what I read in the thread the > > question in the mail that you referenced, as to why > > PGResultSetMetadata does not extend ResultSetMetadata, and as a result > > the getTableName method is mapped onto getBaseTableName, is still > > valid IMO. Especially if the information seems to be readily > > available. Would you consider this change for an upcoming release ? > > > > No the question about extension means that given a PGResultSetMetaData > object you cannot call the standard ResultSetMetaData methods. This is > solely a convenience issue. If you wanted to call both getColumnName and > getBaseColumnName you'd need to maintain two references (one to the > ResultSetMetaData object and another to the PGResultSetMetaData object). > If PGResultSetMetaData extended ResultSetMetaData you'd only need a > reference to the pg version. We have a separate pg specific method > because we believe that function is useful, but does not match the spec > for getTableName. Have you read the entire thread? > > http://archives.postgresql.org/pgsql-jdbc/2004-08/threads.php#00008 Nope, I only browsed over the one you posted earlier (regarding PGResultSetMetaData). I take it that the issue with getColumnName/getBaseColumnName is the same as with getTableName/getBaseTableName ? Let me state what I understand of this issue: it is only possible to return the base (real ?) table name, not the alias. And Sun didn't define this properly in the JDBC spec (at least not in the API and the 3.0 spec, but this might be some useful input for the 4.0 spec ?). However if this is the case, then I don't think your argument given in http://archives.postgresql.org/pgsql-jdbc/2004-08/msg00021.php is valid, because from what I understand of the ResultSetMetaData, the getTableName method returns the name of the column's table, ie. IMO the name of the table where the column is defined in. So in your example this cannot be 'f' but must be 'footable'. I mean, what would I do with 'f' anyway ? IMO it should be possible to build structurally valid select statements from the ResultSetMetaData information which is not the case when returning the aliases. I think this is actually supported by the few places in the JDBC 3 spec that deal with ResultSetMetaData, eg. 13.2.3: "The method PreparedStatement.getMetaData retrieves a ResultSetMetaData object containing a description of the columns that will be returned by a prepared statement when is it executed. The ResultSetMetaData object contains a record for each column being returned. Methods in the ResultSetMetaData interface provide information about the number of columns being returned and the characteristics of each column." Here they specifically speak about the column' characteristics (ie. definition) not the query. IMO the whole intention of the meta data is to be able to determine the database structure by 'reflection' (which incidentially is what I'm doing in my app). As I said, a good reason to ask in the JSR expert group for clarification in the next JDBC standard (if not already done, I havn't checked the current draft). regards, Tom
В списке pgsql-jdbc по дате отправления: