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? Satheesh 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
