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. -- Darren Duncan --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
