Roger Binns wrote:
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
On 01/11/12 18:25, Mark Brand wrote:
You mentioned that this extra AS might help avoid ambiguities and
errors. The only example of this you mentioned was where aliases names
with spaces are not quoted. Do you have cases of this in mind that
wouldn't be syntax errors anyway? In other words, I'm looking for
evidence that "missing AS" really is in the same category of "trailing
semicolons, etc".
Table originally has a column named "price". For various reasons they add
a new column named "price new". Since you can't use bindings in queries
they will either have been written out by hand or composed (eg sprintf).
If the latter code doesn't quote the names then the query includes "price
new" which selects the wrong column and "overwrites" the value returned
for "new". There is a probability of it being detected which depends on
other names in the query/tables and what the consuming code uses. But a
lint that warns about an implicit AS would have a 100% chance of catching
this problem, if is a relevant problem for that code base.
Your example seems to be about column aliases rather than table aliases,
but I grant that examples can be crafted where warning at the absence of
AS in a table alias is helpful. But one can also craft cases where
warning at the *presence* of AS is helpful. Consider this:
CREATE TABLE price (
id PRIMARY KEY,
p INT
)
CREATE TABLE "price as" (
id PRIMARY KEY,
p INT
)
SELECT * FROM price as p
But the programmer intended:
SELECT * FROM "price as" p
and will query the wrong table for years and years until the company
goes bankrupt.
Examples of this kind can be produced to argue either way, so they
cannot decide the matter. Even if we disagree about this, it should be
clear that a lint check for (INNER|LEFT) JOIN without ON constraint is
vastly more valuable.
Mark
_______________________________________________
sqlite-users mailing list
sqlite-users@sqlite.org
http://sqlite.org:8080/cgi-bin/mailman/listinfo/sqlite-users
