Kris Jurka wrote:
> The previous discussion I cited was referring to getColumnName and how
> it really should be referring to the alias of a result, not the column
> itself. That is for "SELECT a AS b FROM c AS d" should return "b" for
> getColumnName(1). If we accept that as true then it follows that
> getTableName(1) should return "d", not "c".
Understood now, thanks. I agree/vote this is the best spec
interpretation/behavior (for its lack of a 'getTableLabel'). It also is
in line with a couple other driver's (inc mysqls') current impls.
Right now we don't have the
> information to return "d" and so we must always return the empty string.
> Getting the base column and table names seems more useful but does not
> appear to be what the javadoc and spec imply as the behavior of the
> standard API methods.
>
> Kris Jurka
>
So to be sure, this (literal and alias name differentiation) actually is
not being provided via the current server V3 protocol or server?
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?
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.
Ken
