I never thought about * as a dangerous thing. The query is shorter and there are less places to modify when I change or add columns. But it is true that VIEWs work with * other way than SELECTs and also because of all this discussion I think I will refrain from using *.
The query I posted was a very quick draft of the real query, it was
SELECT * FROM BinaryTarget INNER JOIN TargetDescription ON BinaryTarget.FeatureItemId = TargetDescription.FeatureItemId;
and I also tried SELECT TargetDescription.*, BinaryTarget.* which did not help. I than thought these are bugs in SQLite and did not try to change the queries. But now I see that even if the parser was modified to return the column names working for me now, it is a very vulnerable part which could easily change in next versions.
Jakub
D. Richard Hipp wrote:
On Mon, 2005-02-28 at 08:48 -0700, Robert Simpson wrote:
5. What we do with the schema information or how well we compute it is
irrelevant.
No. It is exceedingly relevant if you want any cooperation from me in addressing the issue.
There seem to be a lot of people who are emphatic about knowing
which column in which table a value in the result set originated
from. This makes no sense to me. Why do they care? What do these people do with result set values that originate from
expressions or which are constants? What about the result set
of compound selects or of natural joins where the origin column
is ambiguous? If knowing the original column is so important, what do people do with those cases? Disallow them? What do
other database engines (PostgreSQL, Oracle, MySQL) do in the way
of revealing the originating column for result set values? Do
they have some mysterious API that I have never seen?
And why do people care? Can nobody give me a use case where it is important to know what the originating column for a result set value is?
