On Mon, 26 Jan 2015 09:05:32 +0200 RSmith <rsm...@rsweb.co.za> wrote:
> Understand, I do not think these are insurmountable problems, but two > questions arise: > - Who decides the rules for handling it so that it may become > "trusted" by DB users/admins/programmers, if not the SQL standard? My reading of the standard is that the column *name* is what's returned. As such, SQLite would be correct to return a name where there is one, and none where there is not, without distinguishing duplicates. (FWIW that's what SQL Server does.) If SQLite did that in the next release, no applications would break, and new applications would benefit from deterministic, standard column names. My suggestion is a little more complex. I offered it because it seemed to be in the spirit of SQLite's current behavior (assign some kind of name to every column) with the benefit of being deterministic. It's perfectly fine for SQLite to choose nonstandard behavior, and there's no question that the documentation in this case is clear. I think it's a stretch, though, to claim the current behavior is permitted by the standard. I doubt anyone considers it a great feature. It is clearly confusing, witness the topic arising here about once a month. It's more of a quirk: predictable and easy to deal with if you know about it. > how many cpu cycles might be spent to finding suitable column names I'm not convinced there's any real performance issue at stake here. No one's said so. My impression is the current behavior is more an engineering artifact. Because it has a pretty simple workaround, it's being left as-is for now. Which is also understandable. --jkl _______________________________________________ sqlite-users mailing list sqlite-users@sqlite.org http://sqlite.org:8080/cgi-bin/mailman/listinfo/sqlite-users
