On Fri, 2007-06-01 at 12:09 -0400, Art Protin wrote: > > Of course, I've simply transformed the problem to "Does an adequate > > parser exist for your SQL dialect?" but I think we'll just have to > > stipulate that the answer is yes. > > > Ah, there is the disconnect. For my interface I must ask can I code > enough > of a parser for my dialect of SQL in Python so that my module can > properly > handle parameters. There is no reasonable way for my driver to get > the > backend to parse the query and then tell the driver what parameters > are > needed. My driver must dissect the query enough to identify all the > parameters > and "transform them" in the query before passing the query to the > backend.
The same is true for InformixDB. The good news is that making a parser that locates parameter placeholders is not hard. Essentially it boils down to "Look for question marks and colons occurring outside of string literals". There's only a bit of a wrinkle if the SQL dialect allows colons outside of string literals. For example, Informix has datetime literals, a "::" cast notation, and "databasename:tablename" remote-table notation. (I don't know what standard SQL allows.) These situations can be handled by a straightforward heuristic. If a colon follows any character that's neither a colon nor an alphanumeric character, and it's followed by a valid placeholder number or name, it's a placeholder. Otherwise it's considered part of the SQL query. Best regards, -- Carsten Haese http://informixdb.sourceforge.net _______________________________________________ DB-SIG maillist - DB-SIG@python.org http://mail.python.org/mailman/listinfo/db-sig
