Re: Missing functionality in ResultSetMetaData ?

On 8/10/05, Kris Jurka <books(at)ejurka(dot)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