> [EMAIL PROTECTED] wrote: > >> The select proc is only in the pg driver in order to support some >> ancient >> AOLserver 2 functionality that I doubt anyone else uses any more. > > Then should it be removed? (in someone's copious free time...)
Only issue would be legacy sites that may use it. Of course, they could continue with their existing version of the driver, and they likely don't exist anyway? > >> It shouldn't appear in your sqllite3 driver, IMO. > > Could you expand on this? Aren't any legacy AOL2 SQLLite sites, I imagine :) SQLLite's not that ancient, is it???? > You've got way more experience with the db > drivers than I do so I'm inclined to take your advice, but I'm curious > why you think a unified exec is better than separate select/dml/generic > functions. I haven't looked at the oracle db driver forever, but obviously the PG one doesn't differentiate between the two. You call PQExec or whatever it's called, and the library tells you what kind of query it executed. > Aside from that, do you also think the generic function should be > preferred over the specific function if both are defined? Let's put it this way - I know of no problems that have arisen from it being this way. OK, took a teensy bit of cleverness to get the SQLLite3 driver to work right for selects that return no rows, but not much. > Yes, everyone should check their inputs to avoid this, but things > sometimes slip through. Executing a query from an external source isn't simply a matter of "checking your inputs", it's more like checking your brain into the asylum. It's just not in the same class as smuggling in an AND clause due to someone not checking that an integer's an integer or the like. Your select statements should say SELECT, and once you do that, no DROP or DELETE is going to happen no matter what someone does to attempt to smuggle in SQL. > One of my few gripes about the ns_db interface is that you can only pass > raw sql instead of being able to use bind variables. Check out the bindvar emulation for the pg driver in OpenACS mode. It puts a dead stop to sql smuggling because it quotes the values. WHERE foo = :var becomes WHERE foo = '123' which, in PG, works as well as an unquoted 123. But if var is something like "123 or 't'" you get WHERE foo = '123 or ''t''' which is not what was hoped for by the bad guy. -- AOLserver - http://www.aolserver.com/ To Remove yourself from this list, simply send an email to <[EMAIL PROTECTED]> with the body of "SIGNOFF AOLSERVER" in the email message. You can leave the Subject: field of your email blank.
