Petite Abeille wrote:
On Sep 14, 2011, at 8:55 PM, Magnus Thor Torfason wrote:
Now, I get a list of the jobs, and a random selection of employees. I would
have expected an error here. Of course, my actual query was different (this
is based on the Oracle example data base from very old days), but it was
also much more complicated, so I did not notice the error until a bit of
fishing around. So getting an explicit error here would have made things
simpler.
Is there a way to do that? "PRAGMA strict" was one thing I thought about
looking for, but I did not find any such pragma.
Well, this is one of these, hmmm, rather unwelcome features of SQLite. No way
around it except vigilance :/
Actually, I think that this *is* welcome.
For example, in situations like this:
select a.foo, a.bar, sum(b.baz)
from a inner join b using (quux)
group by a.foo;
Now say that "foo" is a primary or unique key of "a".
We already know, then, that since we grouped by a key of a source table, that
all other fields from that table have 1 distinct value per value of "foo", and
so there is no reason to have to say "group by a.foo, a.bar" etc.
As I said, this is *good*.
Now if there is any reason to be more restrictive, it would be that one can't
reference a field directly in the select list that isn't in the group by unless
we are grouping by a key of the table that the fields in the select list are
from, so we have this uniqueness guarantee.
-- Darren Duncan
_______________________________________________
sqlite-users mailing list
sqlite-users@sqlite.org
http://sqlite.org:8080/cgi-bin/mailman/listinfo/sqlite-users
