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]

Reply via email to