Stephan Wehner wrote: > On Sun, Sep 27, 2009 at 5:19 PM, Darren Duncan <dar...@darrenduncan.net> > wrote: > >> Following my previous message to the sqlite-users list, I've done a bit more >> research and decided to escalate my reply to a formal feature request. >> >> 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 ... >> >> ----- >> >> 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, intended >> for >> use in situations where users do want most of the fields from a source but >> don't >> want a few. It would make for much more robust code if users can explicitly >> encode their intentions, meaning say that they want all fields except field >> foo, >> and have them get exactly that (with the expectation that if non-foo fields >> are >> added or removed to the source, they get or don't get those automatically, >> same >> as if they did "SELECT *"). I have seen evidence from both first hand >> experience and from many other developers, that this feature would be very >> helpful to them. And arguably it shouldn't be too terribly complicated for a >> DBMS to implement. >> > > Its a nice idea, but I feel if you use some other interface to SQLite you can > get the same effect. > > On the one hand, I think if you are writing a script/program to fetch > the results, then your > script can assemble the effective columns in the SELECT list (all > columns minus the ones > you want to leave out). Meaning you can write your own C function/Perl > method or what-have-you to > get that list, given the database connection, table name and the > columns-to-leave-out. > I'm not an expert in databases, but as possibly my question triggered this feature request, I can give you the view from a simple user.
Indeed I can get the same functionality from the Python script I'm using. But then I'm beginning to wonder, why I need a database at all ;-) To give another example, a couple of weeks ago I needed to convert one column into a number of columns ( I think it's called pivotting ?), I got a perfect answer from this group, but when I implemented it in the real situation I got an error, not more than 64 tables in a query allowed. So I finaly wrote it myself. Doing a full outer join, is ( in my opinion) more than 50 % redundant information, so I'll probably write a wrapper. These extension works good in a script, but makes the script less readable. > On the other hand I am not sure, but you seem to be interested in > having this feature > so that you get the functionality at the sqlite3 prompt. In which case > I think you can > use a script that has the columns you're interested in, and save > typing that way (type script once, > load many times / type script once, load, change script, load etc.) > > I feel there is great value in not changing software. > Even if the software stays fully backwards compatible ? Now I'm beginning to understand, why (please forgive me to have a judgement as a totally non database expert) such an ugly definition as SQL is still thé database language ;-) cheers, Stef _______________________________________________ sqlite-users mailing list sqlite-users@sqlite.org http://sqlite.org:8080/cgi-bin/mailman/listinfo/sqlite-users
