Mike Meyer wrote: > On Sun, 12 Aug 2007 21:51:33 -0400 Carsten Haese <[EMAIL PROTECTED]> wrote: >> On Sun, 2007-08-12 at 18:12 -0400, Mike Meyer wrote: >>> You're right, in that the existing mechanisms *can* deal with the >>> issues. However, two of the points that comes up over and over again >>> here is "use parameters, don't build the query strings yourself" and >>> "we would rather the module authors do the work than the users". I'm >>> trying to figure out how *either* of those is miscible with "Just use >>> pythons string substitutions for table/column names", much less *both* >>> of them. >> You're right, not having a cross-database mechanism for building queries >> out of variable parts does not quite jibe with those two principles. >> Keep in mind, however, that of the two problems of filling variable >> values into a query and filling variable table/column names into a query >> are two very different problems, and in most applications, the first one >> is more common than the second one by a factor of about a million to one >> or so. > > While I think your order is a little exaggerated, I'll merely point > out that it's a common thing to see when you're writing code that > writes code. SQL pretty much sucks for this, but Python isn't to bad - > and it's one of the most powerful programming technics available - I > seem to use it in every other application. So I'd expect it to become > more common, not less.
about a million to one seems realistic to me. How often does an identifier come from an untrusted source? The only place I really see a use for this is exposing an API to a 2nd developer(s) that is untrusted. isn't it easy enough to validate the identifier against a list pulled from the DB? (as in, you can get a list of valid column names, so any supplied column name has to be in that list.) unless you are allowing ALTER TABLE. hmm... still seems million to one. could be because I have never heard of such a thing, and even have trouble imagining it, so to me it is more like 100 to 0. Carl K _______________________________________________ DB-SIG maillist - DB-SIG@python.org http://mail.python.org/mailman/listinfo/db-sig
