On Mar 19, 2004, at 12:38 AM, Darren Duncan wrote:


On Fri, 19 Mar 2004, Fred Williams wrote:
Yes, about that c.firstname thing...

Do we need to turn in some kind'a formal "enhancement request?" Seems the
feeling of those responding was that a configurable option was most desired.
Perhaps a PRAGMA?


So Richard, in all your spare time, what'd y'a think?

I would say that if this were implemented then is should indeed be PRAGMA
triggered and not be the default option. A default of "leave it the way
you found it" as is done now seems best for a default. It's certainly
more descriptive. The "AS" directive in SQL for explicit renaming seems
the best way to rename for serious work.


Also, an auto-rename as was asked for could have a side-effect of losing
retrieved data in some cases. For example, see the following:


SELECT a.foo, b.foo ...

If the "a." and "b." were stripped off, we would have two returned columns
with identical names. Any application which actually references the
returned data by name and not by column number would only be able to see
one of them. And if the application layer puts a row in an associative
array (a "hash" in Perl talk) of field name/value, then only one column
value would be stored and the other lost.


So you can see how the requested new behaviour would only be useful in
specialized cases and isn't good for a default.

On the other hand, a good way around this problem is that the SQL parser
will throw an error when said behaviour is used, in situations where
the SQL writer does what I demonstrated, citing the fact that
multiple same-named return value columns aren't allowed, requiring the
application writer to use "AS" at least once to get around the error.




I would second this last option... I (personally) would prefer if there was "auto-aliasing" (serious work or not so serious work), and if there was a case where we had a.foo, b.foo then the SQL parser would croak saying, uh huh! so I could go in and add the necessary AS.


Many thanks.


--------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]



Reply via email to