On 2007-06-04 01:08, Carsten Haese wrote:
> On Sat, 2007-06-02 at 20:42 +0200, Paul Boddie wrote:
>> Carsten Haese wrote:
>>> 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 questi
On Mon, 04 Jun 2007 10:41:46 +0200, M.-A. Lemburg wrote
> > We still need to settle the question of what to do about numeric and
> > named styles. There is some support for making both styles mandatory and
> > expecting the API to automatically discern from the query string which
> > parameter styl
On Mon, 2007-06-04 at 10:41 +0200, M.-A. Lemburg wrote:
> I'd suggest to make the current module read-only paramstyle
> attribute and writable connection/cursor attribute which gets
> inherited from connections to cursors.
>
> There's also the problem of parameter type if we allow named
> style. T
On 2007-06-04 14:43, Carsten Haese wrote:
> On Mon, 2007-06-04 at 10:41 +0200, M.-A. Lemburg wrote:
>> I'd suggest to make the current module read-only paramstyle
>> attribute and writable connection/cursor attribute which gets
>> inherited from connections to cursors.
>>
>> There's also the proble
On Mon, 2007-06-04 at 15:00 +0200, M.-A. Lemburg wrote:
> Well, no: I'm saying that it's not a good idea to have the
> signature depend on a parameter.
>
> OTOH, you need such a parameter to allow programmers to query
> the current paramstyle setting, if you do allow multiple param
> styles.
>
>
On 2007-06-04 13:17, Carsten Haese wrote:
> On Mon, 04 Jun 2007 10:41:46 +0200, M.-A. Lemburg wrote
>>> We still need to settle the question of what to do about numeric and
>>> named styles. There is some support for making both styles mandatory and
>>> expecting the API to automatically discern fr
Carsten Haese wrote:
> On Mon, 2007-06-04 at 15:00 +0200, M.-A. Lemburg wrote:
>> Well, no: I'm saying that it's not a good idea to have the
>> signature depend on a parameter.
>>
>> OTOH, you need such a parameter to allow programmers to query
>> the current paramstyle setting, if you do allow mul
On Mon, 2007-06-04 at 15:32 +0200, M.-A. Lemburg wrote:
> Do you really think it's reasonable to have the module parse
> every single SQL statement just to detect the param style ?
Well, at least I don't think it's unreasonable to do so. This parsing is
not expensive and only happens when the quer
On 2007-06-04 16:00, Carsten Haese wrote:
>> So I'm:
>>
>> * +1 on making support one param style mandatory for all
>>implementations
>
> Any one? Let's make named mandatory, then.
I intentionally left this open :-)
We should have a vote on it. Let's gather votes for say two weeks
and then
The following use of the API with MySQL works fine
> items = [1, 2]
> execute('SELECT * from table1 WHERE field1 IN %s', (items,))
resultant query string: SELECT * from table1 WHERE field1 IN ('1', '2')
By contrast, the following yields the message "error in your SQL syntax"
> items = [1]
> exec
M.-A. Lemburg wrote:
> On 2007-06-04 16:00, Carsten Haese wrote:
>>> So I'm:
>>>
>>> * +1 on making support one param style mandatory for all
>>>implementations
>> Any one? Let's make named mandatory, then.
>
> I intentionally left this open :-)
>
> We should have a vote on it. Let's gather
On Mon, 2007-06-04 at 16:32 +0200, M.-A. Lemburg wrote:
> On 2007-06-04 16:00, Carsten Haese wrote:
> >> So I'm:
> >>
> >> * +1 on making support one param style mandatory for all
> >>implementations
> >
> > Any one? Let's make named mandatory, then.
>
> I intentionally left this open :-)
>
On Mon, 2007-06-04 at 10:14 -0500, Carl Karsten wrote:
> Is there a wiki where I can start cataloging the cases for the various cases?
There is http://wiki.python.org/moin/
> I am sure I saw a good case for qmark, but I can't for the life of me
> remember
> what it was. I will eventually dig t
Carsten Haese wrote:
> On Mon, 2007-06-04 at 10:14 -0500, Carl Karsten wrote:
>> Is there a wiki where I can start cataloging the cases for the various cases?
>
> There is http://wiki.python.org/moin/
Hey look, much of this is already there:
Unified Parameter Style
http://wiki.python.org/moin/Db
M.-A. Lemburg wrote at 2007-6-4 16:32 +0200:
> ...
>> Any one? Let's make named mandatory, then.
>
>I intentionally left this open :-)
>
>We should have a vote on it. Let's gather votes for say two weeks
>and then see what the outcome is.
>
>Here's my vote:
>
> +1 on qmark
> +0 on named
> +0 on num
+1 on qmark
+1 on named
-1 on numeric
-1 on format
-1 on pyformat
also +1 on a 'paramstyle' attribute that is settable on connection as
well as cursor
+1 on raising an error if the given statement/arguments dont match
the 'paramstyle'. explicit over implicit, refuse temptation to gue
On 2007-06-04 16:00, Carsten Haese wrote:
>> What happens if you're in qmark style mode and the SQL statement
>> contains substrings which look like named style (but are not
>> intended that way, e.g. think stored procedures) ?
>
> Do you have a concrete example?
Yes: In SAP DB and Max DB trigger
Carsten Haese wrote:
> On Mon, 2007-06-04 at 16:32 +0200, M.-A. Lemburg wrote:
>> On 2007-06-04 16:00, Carsten Haese wrote:
So I'm:
* +1 on making support one param style mandatory for all
implementations
>>> Any one? Let's make named mandatory, then.
>> I intentiona
On Mon, 2007-06-04 at 12:13 -0500, Carl Karsten wrote:
> Hmm, default style brings up a new issue:
> If there will be more than one style, should there be a common
default?
No, the default will be implementation-defined for backwards
compatibility. There will be a common way of switching to the co
On Mon, 04 Jun 2007 16:32:18 +0200, M.-A. Lemburg wrote:
> We should have a vote on it. Let's gather votes for say two weeks
> and then see what the outcome is.
Here's my application programmer's vote:
-1 on qmark
+1 on named
0 on numeric
-1 on format
+1 on pyformat
I was initially set at
+1 on qmark
+0 on named
+0 on numeric
-1 on format
-1 on pyformat -- wish I could vote -2 ;-)
___
DB-SIG maillist - DB-SIG@python.org
http://mail.python.org/mailman/listinfo/db-sig
On Mon, 2007-06-04 at 19:09 +0200, M.-A. Lemburg wrote:
> On 2007-06-04 16:00, Carsten Haese wrote:
> >> What happens if you're in qmark style mode and the SQL statement
> >> contains substrings which look like named style (but are not
> >> intended that way, e.g. think stored procedures) ?
> >
>
Dear folks,
Carsten Haese wrote:
On Mon, 2007-06-04 at 12:13 -0500, Carl Karsten wrote:
Hmm, default style brings up a new issue:
If there will be more than one style, should there be a common
default?
No, the default will be implementation-defined for backwards
compatibility. Ther
On Mon, 2007-06-04 at 14:03 -0400, Art Protin wrote:
> If users can not code to a common standard with Python, they will
> code to a common
> standard with JAVA & JDBC.
Shoehorning all databases into one true interface may be fine for the
Bondage And Domination world of Java, but here in the
Art Protin wrote:
> Dear folks,
>Carsten Haese wrote:
>
>> On Mon, 2007-06-04 at 12:13 -0500, Carl Karsten wrote:
>>
>>
>>> Hmm, default style brings up a new issue:
>>> If there will be more than one style, should there be a common
>>>
>> default?
>>
>> No, the default will be impl
25 matches
Mail list logo
