db-derby-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Satheesh Bandaram <sathe...@Sourcery.Org>
Subject Re: About improvement of DERBY-134
Date Sun, 13 Mar 2005 19:32:13 GMT
Derby actually generates two different names... 1) Unique name for
unnamed references 2) Final exposed names for top level unnamed result
columns. The unique names are of the form 'SQLCol<Number>' and final
exposed names, that IJ shows, are of the form '<Number>'. The number
part of the names could be different. (Eg: 'SQLCol5' may map to '1' as
exposed name)

The SQLCol unique names can't be guessed correctly by end users. It may
change depending on how the query is compiled and can change totally
unexpectedly.(Like adding an extra union at the end of the query could
change top level result column names) So these are definitely not
suitable to be used by end users. It may be possible to use final
exposed names (like '1', '2') in order by clause, but Derby currently
doesn't allow it. It is not consistant to allow this only under some new
code path, as a side effect. We have to consistantly change it all over.
I don't know what the SQL standard says about this... I don't want to
look at that huge spec on a Sunday. :-)

I am not sure we should, even if we could... Like you said, these
numbers are implementation dependent, change from one vendor to another
and may even change from one release to another.  Shouldn't querries
instead use explicit aliasing to avoid all confusion, which is standards
based and portable?


Jeremy Boynes wrote

> I'm not so sure - I thought expressions were given implementation
> dependent names that could be referenced in a sort key. In our case
> the name is "SQLCol1" so referencing that would be valid but
> non-portable.
> I'm curious why ij is not labeling the columns that way and whether it
> should.
> -- 
> Jeremy

View raw message