On Fri, 10 Aug 2007 20:24:17 -0400 Carsten Haese <[EMAIL PROTECTED]> wrote:
> On Fri, 2007-08-10 at 16:11 -0400, Mike Meyer wrote:
> > 2) You have to use '%%' to get a real '%' into the query.
> > As for #2, yes, you have to use '%%' to insert a single '%'. How do
> > the other paramstyles deal with wanting to get their significant
> > character into the query? From reading the last few months of
> > archives, it seems that they don't.
> Actually, they do (or at least they should, and InformixDB certainly
> does). SQL already has a standard way of treating parameter markers as
> literals: Apostrophes. A question mark is a literal question mark if and
> only if it occurs inside apostrophes. Otherwise, it's a parameter
> marker. The same principle is true for colon-identifier tokens.
Well, InformixDB has a way that works. I can think of at least two
other databases that it won't work for - or at least, will have
surprising consequences for users. That's not the same thing as the
paramstyle having a way.
> > If the goal is to be able to
> > write code that will port between db modules - or even databases -
> > without modification, then having a defined way to deal with this
> > issue is clearly better than punting to the module authors. After all,
> > it's the latter that created the current situation.
> As I said, there is a defined way: Don't treat things that look like
> parameter markers as parameter markers if they appear inside
> apostrophes. This may require a simple parser in the API module, but I
> prefer placing a burden on a dozen API module authors over placing a
> burden on thousands of application developers.
Well, that's a way. The problem is, it's not defined in the PEP. Other
modules don't do that (since pysqlite is bundled these days, it's easy
to verify that indeed, it doesn't behave this way).
I do agree that the module authors ought to have to deal with this
rather than the users. But letting each module author do it however
they feel is best only helps users who are writing for a specific
module; users trying to write code that's portable between modules
and/or databases are better served by a specification that applies to
all modules, even if it adds the burden of flagging significant
characters as literal.
If a new version of the PEP is going to require supporting a parameter
style - which I believe is a good thing - it should be one that's at
least as explicit as the most explicit of the current parameter
styles. Which means the PEP needs to lay out the rules for when the
parameters are recognized as such and when they aren't.
<mike
--
Mike Meyer <[EMAIL PROTECTED]> http://www.mired.org/consulting.html
Independent Network/Unix/Perforce consultant, email for more information.
_______________________________________________
DB-SIG maillist - DB-SIG@python.org
http://mail.python.org/mailman/listinfo/db-sig
