On Wed, 2007-05-30 at 22:53 -0400, Michael Bayer wrote:
> On May 30, 2007, at 11:17 AM, Vern Cole wrote:
>
> >
> > c.execute("SELECT (CASE WHEN infos.pk <", p1,
> > "THEN", p2,
> > "WHEN (infos.pk >=", p3,
> > " AND infos.pk <", p4,
> > ")THEN", p5,
> > "END) AS x, infos.pk, infos.info FROM infos")
> > ###^^^
> >
> > I think that most people would find the function parameter notation
> > much easier to read, write, and maintain than the qmark version.
> > There is no question what parameter goes where, no counting, no
> > wondering how python or your reader will interpret it. And it will
> > look like the built-in python 3 print() function. ;-)
> >
>
> seriously ? how would it differentiate a string value that is part
> of the generated SQL vs. a string value that is intended to be a bind
> parameter ?
Differentiating parameters from query bits is easy, they alternate, but
I vote -1 on Vern's proposal for all the other reasons you mentioned.
The same readability of injecting variables into an SQL query can
already be achieved with named parameters and locals():
c.execute("""SELECT (CASE
WHEN infos.pk < :p1 THEN :p2
WHEN (infos.pk >= :p3 AND infos.pk < :p4) THEN :p5
END) AS x, infos.pk, infos.info FROM infos""", locals() )
> my vote for paramstyles would be, everyone supports qmark and named,
> and we're done. the rest of the styles are all redundant.
That makes +3 votes for making qmark mandatory (you, Marc-Andre, and
myself). I'm not sure what your stance is on format, pyformat, and
numeric. Are you allowing them optionally or are you proposing that they
be deprecated/removed? I would vote -1 on completely removing numeric
because I don't think it's redundant.
I personally like named style, but I'm +0 on making it required. If it
were required, you'd have to specify how the API is expected to
differentiate between qmark and named. Do you expect the API to
auto-detect the parameter style from the query string, or do you expect
some kind of switching mechanism?
Best regards,
--
Carsten Haese
http://informixdb.sourceforge.net
_______________________________________________
DB-SIG maillist - [email protected]
http://mail.python.org/mailman/listinfo/db-sig
