On May 23, 2013, at 10:59 AM, M.-A. Lemburg wrote:
>> 2. the cursor knows upfront that it will deal with a single "positional" or
>> "named" parameter style. When execute() is called, it examines the
>> parameter argument to see if it is a sequence or a mapping. Based on that,
>> it determ
On 22.05.2013 00:07, Vernon D. Cole wrote:
> I think that we should be careful not to mandate any sophisticated grammar
> processing of the query string. The most notice we should take of comments
> would be to suggest that any reformatting operation might choose to stop at
> a double dash.
> /*
On 22.05.2013 00:52, Michael Bayer wrote:
>
> On May 21, 2013, at 3:24 PM, M.-A. Lemburg wrote:
>
>> On 21.05.2013 20:55, Michael Bayer wrote:
>>>
>>> On May 21, 2013, at 2:30 PM, M.-A. Lemburg wrote:
>>>
Something we do need to address in a paramstyle spec for
qmark and named is
On 22.05.2013 11:58, Vernon D. Cole wrote:
The major difference -- the change of paradigm (to put it in elegant
terms) -- between api 2 and our proposed api 3, is our use of 'paramstyle'.
In api 2, we attempted to use it to tell our client programmer how to
talk to us. That did not work out too
The major difference -- the change of paradigm (to put it in elegant terms)
-- between api 2 and our proposed api 3, is our use of 'paramstyle'.
In api 2, we attempted to use it to tell our client programmer how to talk
to us. That did not work out too well.
In api 3, we propose to offer the serv
On Tue, May 21, 2013 at 7:30 PM, M.-A. Lemburg wrote:
> However, escaping doesn't strike me as one of the important
> details, since I have yet to find an example where you'd
> actually need escaping :-)
Uhm, I thought I'd shown a few of them. But they may have been
scattered around in the long
On May 21, 2013, at 3:24 PM, M.-A. Lemburg wrote:
> On 21.05.2013 20:55, Michael Bayer wrote:
>>
>> On May 21, 2013, at 2:30 PM, M.-A. Lemburg wrote:
>>
>>>
>>> Something we do need to address in a paramstyle spec for
>>> qmark and named is SQL comments. Perhaps easiest would be
>>> to disal
I think that we should be careful not to mandate any sophisticated grammar
processing of the query string. The most notice we should take of comments
would be to suggest that any reformatting operation might choose to stop at
a double dash.
/* C style */ comments and other non-ANSI-standard stand
On Tue, May 21, 2013 at 3:54 PM, Chris Clark wrote:
> I personally would like to see qmark the only required format (with others
> allowed), and have (as part of the spec) a reference implementation that
> could convert from qmark into X (under a permissive license) that driver
> authors could the
On Tue, 21 May 2013 21:24:19 +0200, M.-A. Lemburg wrote:
On 21.05.2013 20:55, Michael Bayer wrote:
On May 21, 2013, at 2:30 PM, M.-A. Lemburg wrote:
Something we do need to address in a paramstyle spec for
qmark and named is SQL comments. Perhaps easiest would be
to disallow them in SQL stat
On 21.05.2013 20:55, Michael Bayer wrote:
>
> On May 21, 2013, at 2:30 PM, M.-A. Lemburg wrote:
>
>>
>> Something we do need to address in a paramstyle spec for
>> qmark and named is SQL comments. Perhaps easiest would be
>> to disallow them in SQL statements passed to .execute*().
>
> um, mean
On May 21, 2013, at 2:30 PM, M.-A. Lemburg wrote:
>
> Something we do need to address in a paramstyle spec for
> qmark and named is SQL comments. Perhaps easiest would be
> to disallow them in SQL statements passed to .execute*().
um, meaning no SQL comments allowed in a call to cursor.execute
12 matches
Mail list logo
