Re: Support for DatabaseMetadata: getCatalogName, getTableName,

>> If so, does anyone know off hand if V3 is somehow extensible; i.e can
>> we add in metadata without breaking apps or major version?
>>
>
> No the RowDescription message is fixed:
>

Oh, man.

>
>> Again, just trying to get an idea of how near or far off this may be.
>> I think there are several high level object persistence wrappers out
>> there that depend (right or wrong) on table names/aliases to
>> reconstitute objects from selects and natural/inner joins.
>>
>
> It's a ways off and even if it was working you have to think about
> things like self joins and calculated results.

Well if the app was sending complex queries yes. But I don't think its
an issue for simple data sweeps:

select * from t1, t2 where t1.pk=t2.fk

With getTableName its possible to build hashtable keys, etc from this
even when t1 and t2 both contains a 'pk' -- which is kind of nice since
one need'nt name the column in the usual tablename_pk format, and
becasue the table name itself implies the tablename_pk format that would
normally be assigned it's column.

while (rs.next())
{
    for (int=1;i<cols;i++)
        hash.put(rs.getTableName(i)+"."+rs.getColumnLabel(i));
}

or to use trees of hashtables (avoiding the StringBuffer)
((Hashtable)tbls->(Hashtable)cols)

Tad off topic on my part, apologies.

ken