-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Darren Duncan wrote: > I was initially going to file a ticket, but it seems that non-registered > SQLite > developers can't do that anymore, and we're supposed to do it on sqlite-users > where a non-registered developer would then distill list chatter to real > tickets. So here I go ...
That would be "where a *registered* developer ..." :-) > I propose that SQLite (and other DBMSs, and the SQL standard) add support for > explicitly naming a list of result fields that they do *not* want, Something like this already exists for virtual tables. Look for "hidden" in the xCreate section at http://www.sqlite.org/cvstrac/wiki?p=VirtualTableMethods The same mechanism does not exist for normal tables. > intended for > use in situations where users do want most of the fields from a source but > don't > want a few. [I am playing devil's advocate here. Please pardon the horns :] What is the harm in the extra fields being returned? Sure they take up a few bytes more space but that isn't a big deal. In tables where there may be a large blob column it is mostly likely that the developer has already "optimised" the situation (eg point to another table, use files, make sure column isn't requested). Also if your table has so many columns that many are unrelated then shouldn't you be doing some form of normalization rather than this? A second note is that there is a very clear distinction between users and developers (and administrators if using Oracle/postgres/mysql etc) although developers using SQLite are SQLite users. In any event a user of a program using SQLite should never encounter this issue. Nor should most developers since they designed their schema around their uses. > It would make for much more robust code if users can explicitly > encode their intentions, What is testing for? What are comments for? > I have seen evidence from both first hand > experience and from many other developers, that this feature would be very > helpful to them. I still don't see how? The only way is if they say "except" a certain field that doesn't exist and so get a SQL error. I don't see how the proposal saves people, money or time. > And arguably it shouldn't be too terribly complicated for a > DBMS to implement. Or for you to implement it in your code :-) You could have a function that takes a table name and a list of columns to exclude and returns a string to insert into your query of the desired columns, comma separated. (pragma table_info will get you the column names.) Implementing something like this in your codebase (plus perhaps making the function available as open source) would give your argument substantiation. For example you could point to how many bugs it helped catch, developer productivity, adoption by other projects (this points to the need) etc. There are a lot of proposals for enhancements to SQLite like this. As was discussed in a previous thread it then causes the enhancement to become permanent until SQLite 4. It will always have to be there, always have to be supported and tested, cannot change (much) etc. ["D" related stuff elided] Unfortunately the various names and symbols aren't conducive to Google searches (it keeps matching smileys!). Do you have any examples of real world source code using this kind of functionality, or some equivalent that has the same effect? Roger -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.9 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iEYEARECAAYFAkrAMYUACgkQmOOfHg372QTkoQCfVwf9FQu+tXRkhXjmoGtvCeP6 oecAn2UgRXhIrudiougq98QrP532AKjQ =M5ns -----END PGP SIGNATURE----- _______________________________________________ sqlite-users mailing list sqlite-users@sqlite.org http://sqlite.org:8080/cgi-bin/mailman/listinfo/sqlite-users
