Lawrence D'Oliveiro <[EMAIL PROTECTED]> wrote:
> In message <[EMAIL PROTECTED]>, LI wrote:
>
> execfile("QuoteSQL.py")
> EscapeSQLWild(r"\%")
>> '%'
> SQLString("%" + EscapeSQLWild(r"\%") + "%")
>> '"%%%"'
> EscapeSQLWild(r"\%") == r"\\%"
>> True
> SQLString("%" +
In message <[EMAIL PROTECTED]>, LI wrote:
execfile("QuoteSQL.py")
EscapeSQLWild(r"\%")
> '%'
SQLString("%" + EscapeSQLWild(r"\%") + "%")
> '"%%%"'
EscapeSQLWild(r"\%") == r"\\%"
> True
SQLString("%" + EscapeSQLWild(r"\%") + "%") == r'"%%%"'
> True
With the
In message <[EMAIL PROTECTED]>, I wrote:
> def EscapeSQLWild(Str) :
> """escapes MySQL pattern wildcards in Str."""
> Result = []
> for Ch in str(Str) :
> if Ch == "%" or Ch == "_" :
> Result.append("\\")
> #end if
> R
Lawrence D'Oliveiro <[EMAIL PROTECTED]> wrote:
> In message <[EMAIL PROTECTED]>, Duncan Booth wrote:
>> Deary me. Did you actually test out that bit of code before you
>> posted it?
>
execfile("QuoteSQL.py")
EscapeSQLWild(r"\%")
> '%'
SQLString("%" + EscapeSQLWild(r"\%") + "%")
In message <[EMAIL PROTECTED]>, Duncan Booth wrote:
> Lawrence D'Oliveiro <[EMAIL PROTECTED]> wrote:
>
>> I'm assuming you mean, how would you get from a Python expression to a
>> MySQL clause that looks like
>>
>> name like "%%%"
>>
>> (wildcard % followed by literal backslash \\ follo
Lawrence D'Oliveiro <[EMAIL PROTECTED]> wrote:
> I'm assuming you mean, how would you get from a Python expression to a
> MySQL clause that looks like
>
> name like "%%%"
>
> (wildcard % followed by literal backslash \\ followed by literal
> percent \% followed by wildcard %.) That's eas
In message <[EMAIL PROTECTED]>, Duncan Booth wrote:
> Lawrence D'Oliveiro <[EMAIL PROTECTED]> wrote:
>
>>> You are still missing the point. I'm not talking about generating a
>>> MySQL string literal, I'm talking about preventing wildcards
>>> characters having their special meaning when using th
Lawrence D'Oliveiro <[EMAIL PROTECTED]> wrote:
>> You are still missing the point. I'm not talking about generating a
>> MySQL string literal, I'm talking about preventing wildcards
>> characters having their special meaning when using the string as a
>> parameter in cursor.execute.
>
> But that'
Lawrence D'Oliveiro wrote:
> In message <[EMAIL PROTECTED]>, Duncan Booth wrote:
>
> > Lawrence D'Oliveiro <[EMAIL PROTECTED]> wrote:
> >
> >> In message <[EMAIL PROTECTED]>, Duncan Booth
> >> wrote:
> >>
> >>> Lawrence D'Oliveiro <[EMAIL PROTECTED]> wrote:
> >>>
> def EscapeSQLWild(Str)
In message <[EMAIL PROTECTED]>, Duncan Booth wrote:
> Lawrence D'Oliveiro <[EMAIL PROTECTED]> wrote:
>
>> In message <[EMAIL PROTECTED]>, Duncan Booth
>> wrote:
>>
>>> Lawrence D'Oliveiro <[EMAIL PROTECTED]> wrote:
>>>
def EscapeSQLWild(Str) :
"""escapes MySQL pattern wild
Lawrence D'Oliveiro <[EMAIL PROTECTED]> wrote:
> In message <[EMAIL PROTECTED]>, Duncan Booth
> wrote:
>
>> Lawrence D'Oliveiro <[EMAIL PROTECTED]> wrote:
>>
>>> def EscapeSQLWild(Str) :
>>> """escapes MySQL pattern wildcards in Str."""
>>> Result = []
>>> for Ch in
In message <[EMAIL PROTECTED]>, Duncan Booth wrote:
> Lawrence D'Oliveiro <[EMAIL PROTECTED]> wrote:
>
>> def EscapeSQLWild(Str) :
>> """escapes MySQL pattern wildcards in Str."""
>> Result = []
>> for Ch in str(Str) :
>> if Ch == "%" or Ch == "_" :
>>
Lawrence D'Oliveiro <[EMAIL PROTECTED]> wrote:
> def EscapeSQLWild(Str) :
> """escapes MySQL pattern wildcards in Str."""
> Result = []
> for Ch in str(Str) :
> if Ch == "%" or Ch == "_" :
> Result.append("\\")
> #end if
>
Lawrence D'Oliveiro wrote:
> In message <[EMAIL PROTECTED]>, Steve
> Holden wrote:
[...]
>>Sadly your assertions alone fail to convince. Perhaps you could provide
>>a concrete example?
>
>
> Sorry, that turned out to be wrong. You do in fact need to escape the
> escapes on wildcards.
Thank you.
In message <[EMAIL PROTECTED]>, Steve
Holden wrote:
> Lawrence D'Oliveiro wrote:
>
>> In message <[EMAIL PROTECTED]>, Duncan Booth wrote:
>>
>>>In particular it currently turns newlines in backslash followed by n
>>>which (since MySQL ignores the extra backslash escape) is equivalent to
>>>turnin
In message <[EMAIL PROTECTED]>, Steve
Holden wrote:
> Lawrence D'Oliveiro wrote:
>> In message <[EMAIL PROTECTED]>, Steve
>> Holden wrote:
>>
>>
>>>Lawrence D'Oliveiro wrote:
>>>
In message <[EMAIL PROTECTED]>, Steve
Holden wrote:
>When you use the DB API correctly and
In message <[EMAIL PROTECTED]>, Sybren Stuvel
wrote:
> Tim Chase enlightened us with:
>> >>> cur.execute("select * from people where last_name in (%s)" %
>> ','.join('%s' for i in xrange(len(t))),
>> t)
>
> But since the value of 'i' isn't used at all, it can be abbreviated
> to:
>
cur.exec
Dennis Lee Bieber wrote:
> So.. In the case of MySQLdb, one can modify the dictionary of quote
> converters... Seems like one could create a "class" for "LIKE" wildcard
> strings, rather than just pass plain strings, and add that "type" to the
> list of quote converters. That way, one's cust
Sybren Stuvel wrote:
> I didn't care anything about all that. I just found the way I wrote it
> somewhat easier to read.
absolutely.
--
http://mail.python.org/mailman/listinfo/python-list
Fredrik Lundh enlightened us with:
> and now we're waiting for the "['%s']*len(t)" vs. "'%s' for i in t"
> benchmarks (and the "consistency is more important than efficiency"
> and "creating extra objects is conceptually wrong" followups, and
> the "it depends on what you mean by" followups to the
Lawrence D'Oliveiro wrote:
> In message <[EMAIL PROTECTED]>, Duncan Booth wrote:
>
>
>>However, your QuoteSQL messes up every time because it wraps double
>>quotes round the whole string, so it isn't suitable for use with
>>parameterised queries at al
Tim Chase enlightened us with:
> >>> cur.execute("select * from people where last_name in (%s)" %
> ','.join('%s' for i in xrange(len(t))),
> t)
But since the value of 'i' isn't used at all, it can be abbreviated
to:
>>> cur.execute("select * from people where last_name in (%s)" %
> "Need" is a strong word unless something like the
> following doesn't work for some reason:
>
> cur.execute("select * from people where last_name in
> (%s,%s,%s)", (name1, name2, name3) )
Which could be nicely generalized to something like
>>> t = (name1, name2, name3)
>>> cur.execute("s
Lawrence D'Oliveiro wrote:
> In message <[EMAIL PROTECTED]>, Steve
> Holden wrote:
>
>
>>Lawrence D'Oliveiro wrote:
>>
>>>In message <[EMAIL PROTECTED]>, Steve
>>>Holden wrote:
>>>
>>>
>>>
When you use the DB API correctly and paramterise your queries you still
need to quote wildcards in
Sybren Stuvel wrote:
> >>> cur.execute("select * from people where last_name in (%s)" %
> >>> ','.join('%s' for i in t), t)
and now we're waiting for the "['%s']*len(t)" vs. "'%s' for i in t" benchmarks
(and the
"consistency is more important than efficiency" and "creating extra objects is
con
Lawrence D'Oliveiro wrote:
> In message <[EMAIL PROTECTED]>, Duncan Booth wrote:
>
>
>>However, your QuoteSQL messes up every time because it wraps double
>>quotes round the whole string, so it isn't suitable for use with
>>parameterised queries at al
In message <[EMAIL PROTECTED]>, Sybren Stuvel
wrote:
> Lawrence D'Oliveiro enlightened us with:
>> You're proposing two separate functions:
>>
>> 1) quoting of non-wildcard specials
>> 2) quoting of wildcard specials
>
> I'm suggesting functions based on the role of the string they need t
On Tue, 2006-09-26 at 07:08, Lawrence D'Oliveiro wrote:
> So yes, there should be two separate functions, one for escaping
> non-wildcard specials, and one for escaping wildcards.
>
> > You only need the first one, since every database interface that
> > follows PEP 249.
>
> You still need the se
In message <[EMAIL PROTECTED]>, Duncan Booth wrote:
> However, your QuoteSQL messes up every time because it wraps double
> quotes round the whole string, so it isn't suitable for use with
> parameterised queries at all. If you care to modify it to work in that
> situat
Lawrence D'Oliveiro enlightened us with:
> Because quoting the wildcards introduces backslash specials before
> each wildcard. Quoting non-wildcards then causes those backslashes
> to be doubled, which means they escape themselves instead of the
> wildcards.
I don't know about other DBMSes, but in
Lawrence D'Oliveiro enlightened us with:
> You're proposing two separate functions:
>
> 1) quoting of non-wildcard specials
> 2) quoting of wildcard specials
I'm suggesting functions based on the role of the string they need to
escape, not the characters in that string.
1) Quoting of
In message <[EMAIL PROTECTED]>, Sybren Stuvel
wrote:
> Lawrence D'Oliveiro enlightened us with:
>> The trouble with this is that, instead of offering extra functionality,
>> it leaves the door open to making two stupid mistakes:
>>
>> 2) quoting of wildcards BEFORE quoting of non-wildcards
>
> matching a newline.
>
> And how would you get my QuoteSQL routine, as written, to make the same
> mistake you did?
If you think I made a mistake I'm afraid you'll have to tell me what it
was. I'm unable to read your mind.
However, your QuoteSQL messes up every time b
Lawrence D'Oliveiro enlightened us with:
> The trouble with this is that, instead of offering extra functionality, it
> leaves the door open to making two stupid mistakes:
>
> 2) quoting of wildcards BEFORE quoting of non-wildcards
Why is this a "stupid" mistake in your view? Please explain th
Sybren Stuvel wrote:
> I'm suggesting functions based on the role of the string they need to
> escape, not the characters in that string.
>
> 1) Quoting of wildcard strings for a query using LIKE etc.
> 2) Quoting of values for putting into queries.
it's actually quite amusing that some
In message <[EMAIL PROTECTED]>, Duncan Booth wrote:
> The spurious escaping of the apostrophe does no harm, but spuriously
> escaping a newline makes the select match the letter 'n' insteal of
> matching a newline.
And how would you get my QuoteSQL routine, as written,
In message <[EMAIL PROTECTED]>, Steve
Holden wrote:
> Lawrence D'Oliveiro wrote:
>>
>> In message <[EMAIL PROTECTED]>, Steve
>> Holden wrote:
>>
>>
>>>When you use the DB API correctly and paramterise your queries you still
>>>need to quote wildcards in search arguments, but you absolutely
>>>sh
Steve Holden wrote:
> Ah, so your quoting function will deduce the context in which arguments
> intended for parameter substitution in the query will be used? Or are
> you suggesting that it's unwise to rely on autoquoted parameters? That
> could have a serious impact on the efficiency of some
Lawrence D'Oliveiro wrote:
> In message <[EMAIL PROTECTED]>, Steve
> Holden wrote:
>
>
>>When you use the DB API correctly and paramterise your queries you still
>>need to quote wildcards in search arguments, but you absolutely
>>shouldn't quote the other SQL specials.
>>
>>That's what parameteri
In message <[EMAIL PROTECTED]>, Jon Ribbens wrote:
> In article <[EMAIL PROTECTED]>, Lawrence D'Oliveiro wrote:
>> You're proposing two separate functions:
>>
>> 1) quoting of non-wildcard specials
>> 2) quoting of wildcard specials
>
> Lawrence, you're wrong...
Did I misunderstand what
In article <[EMAIL PROTECTED]>, Lawrence D'Oliveiro wrote:
> You're proposing two separate functions:
>
> 1) quoting of non-wildcard specials
> 2) quoting of wildcard specials
Lawrence, you're wrong in this thread for the same reason you were
right in the cgi.escape thread. Escaping gener
In message <[EMAIL PROTECTED]>, Steve
Holden wrote:
> When you use the DB API correctly and paramterise your queries you still
> need to quote wildcards in search arguments, but you absolutely
> shouldn't quote the other SQL specials.
>
> That's what parameterised queries are for on the first pla
g of non-wildcard specials only
2) quoting of both non-wildcard and wildcard specials
Or:
* A single function that performs either of the above two operations,
depending on a boolean flag--which is what QuoteSQL does.
I guess I don't have a strong preference for which way we do
Lawrence D'Oliveiro enlightened us with:
>> An escaping function should be small and not do all kinds of
>> escaping for different situations at once.
>
> Even when the two situations are related?
Yup, even then. Different situations need different escaping
functions.
Sybren
--
Sybren Stüvel
St
Lawrence D'Oliveiro <[EMAIL PROTECTED]> wrote:
>> Indeed. An escaping function should be small and not do all kinds of
>> escaping for different situations at once.
>
> Look at it this way: there is _no_ case where you need escaping of
> wildcards without also escaping other specials.
You need t
looked for literal percents.
>>
>>But of course.
>>
>>
>>>This could be an argument for having a utility function to escape
>>>the wildcards for this sort of situation, but certainly not an
>>>argument for his proposed QuoteSQL.
>>
>>Indeed
This could be an argument for having a utility function to escape
>> the wildcards for this sort of situation, but certainly not an
>> argument for his proposed QuoteSQL.
>
> Indeed. An escaping function should be small and not do all kinds of
> escaping for different situatio
This could be an argument for having a utility function to escape
>> the wildcards for this sort of situation, but certainly not an
>> argument for his proposed QuoteSQL.
>
> Indeed. An escaping function should be small and not do all kinds of
> escaping for different situ
In message <[EMAIL PROTECTED]>, Duncan Booth wrote:
> Lawrence D'Oliveiro <[EMAIL PROTECTED]> wrote:
>
>>> This could be an argument for having a utility function to escape the
>>> wildcards for this sort of situation, but certainly not an argument for
sort of situation, but certainly not an
> argument for his proposed QuoteSQL.
Indeed. An escaping function should be small and not do all kinds of
escaping for different situations at once.
Sybren
--
Sybren Stüvel
Stüvel IT - http://www.stuvel.eu/
--
http://mail.python.org/mailman/listinfo/python-list
Lawrence D'Oliveiro <[EMAIL PROTECTED]> wrote:
>> This could be an argument for having a utility function to escape the
>> wildcards for this sort of situation, but certainly not an argument for
>> his proposed QuoteSQL.
>
> Why not? That is exactly one of the
looked for literal percents.
>
> This could be an argument for having a utility function to escape the
> wildcards for this sort of situation, but certainly not an argument for
> his proposed QuoteSQL.
Why not? That is exactly one of the options my QuoteSQL offers.
--
http://mail.python.org/mailman/listinfo/python-list
ncluding all sorts of quotes, newlines, backslashes etc. in the name.
>
I think his point was that any '%' characters inside name act like
wildcards whereas his version looked for literal percents.
This could be an argument for having a utility function to escape the
wildcards for this
Lawrence D'Oliveiro enlightened us with:
>> Wouldn't this be a whole lot better?
>>
>> cursor.execute(
>> "select * from details where person_name like ?",
>> '%' + name + '%'
>> )
>
> No. Can you figure out why?
Ok, should have tested it better. This works fine on my machine,
though:
cu
In message <[EMAIL PROTECTED]>, Sybren Stuvel
wrote:
> Lawrence D'Oliveiro enlightened us with:
>> "select * from details where person_name like"
>> " concat(\"%%\", %s, \"%%\")" \
>> % \
Lawrence D'Oliveiro enlightened us with:
> "select * from details where person_name like"
> " concat(\"%%\", %s, \"%%\")" \
> % \
> QuoteSQL(name, True)
Wouldn't this be a whole lot better?
cur
* from details where person_name like"
" concat(\"%%\", %s, \"%%\")" \
% \
QuoteSQL(name, True)
--
http://mail.python.org/mailman/listinfo/python-list
Lawrence D'Oliveiro wrote:
> In message <[EMAIL PROTECTED]>, Sybren Stuvel
> wrote:
>
>
>>Lawrence D'Oliveiro enlightened us with:
>>
>>>Why doesn't MySQLdb provide a function like this:
>>
>>Because generally you're able to pass newlines and the like just fine.
>>You can even store binary data i
Lawrence D'Oliveiro wrote:
>>> elif Ch == "'" or Ch == "\"" or Ch == "\\" :
>>> Ch = "\\" + Ch
>> Always sad to see an SQL DBMS willfully violate the SQL standard.
>
> Why is that a violation of SQL?
Taking another look, I might be wrong: Your code uses double quotes, and
sin
Robert Kern wrote:
> Anders J. Munch wrote:
>
>> Always sad to see an SQL DBMS willfully violate the SQL standard.
>
> You must be a constantly depressed person, then. :-)
Nah, I just look the other way most of the time *g*
- Anders
--
http://mail.python.org/mailman/listinfo/python-list
Lawrence D'Oliveiro enlightened us with:
> Yes, I have done blobs. Still need a quoting function for the
> specials, though.
Why? What makes your data so different from mine? I can store newlines
and the likes just fine in a regular text field.
Sybren
--
Sybren Stüvel
Stüvel IT - http://www.st
In message <[EMAIL PROTECTED]>, Sybren Stuvel
wrote:
> Lawrence D'Oliveiro enlightened us with:
>> Why doesn't MySQLdb provide a function like this:
>
> Because generally you're able to pass newlines and the like just fine.
> You can even store binary data into a BLOB column.
Yes, I have done bl
Lawrence D'Oliveiro enlightened us with:
> Why doesn't MySQLdb provide a function like this:
Because generally you're able to pass newlines and the like just fine.
You can even store binary data into a BLOB column.
Sybren
--
Sybren Stüvel
Stüvel IT - http://www.stuvel.eu/
--
http://mail.pytho
Anders J. Munch wrote:
> Always sad to see an SQL DBMS willfully violate the SQL standard.
You must be a constantly depressed person, then. :-)
--
Robert Kern
"I have come to believe that the whole world is an enigma, a harmless enigma
that is made terrible by our own mad attempt to interpr
In message <[EMAIL PROTECTED]>, Anders J. Munch
wrote:
> Lawrence D'Oliveiro wrote:
>> Why doesn't MySQLdb provide a function like this:
>>
>> def QuoteSQL(Str, DoWild) :
>> """returns a MySQL string literal which evaluates to S
Lawrence D'Oliveiro wrote:
> Why doesn't MySQLdb provide a function like this:
>
> def QuoteSQL(Str, DoWild) :
> """returns a MySQL string literal which evaluates to Str. Needed
> for those times when MySQLdb's automatic quoting isn't good
Lawrence D'Oliveiro wrote:
> Why doesn't MySQLdb provide a function like this:
Because the author has read PEP 8?
--
http://mail.python.org/mailman/listinfo/python-list
Why doesn't MySQLdb provide a function like this:
def QuoteSQL(Str, DoWild) :
"""returns a MySQL string literal which evaluates to Str. Needed
for those times when MySQLdb's automatic quoting isn't good enough."""
Result = []
68 matches
Mail list logo
