[DB-SIG] In praise of pyformat

[Mike Meyer]

On Sun, 12 Aug 2007 17:05:44 -0400 Carsten Haese <carsten at uniqsys.com> wrote:

> -1. The problem that your proposal is trying to solve doesn't exist. For
> supplying variable values, parameter binding as it is (with the addition
> of making qmark and named mandatory as was decided recently) is
> perfectly adequate.

Maybe. Maybe not. Not at issue.

> For supplying variable table names, column names,
> where clauses, and other syntax elements, string formatting seems
> perfectly adequate.

It may seem adequate, but it isn't. Table/column names from external
sources have to deal with the exact same set of data injection issues
that values from external sources do.

> Maybe you should illustrate the kinds of problems you're encountering in
> whatever it is you're doing that makes you feel that the existing way is
> inadequate. Right now, you're coming off somewhat trollish by making
> proposals for solving non-existent problems.

I didn't say the existing way is inadequate; it can be fine (except
for portability issues). The proposed changes - basically including
killing off the mechanisms that do work - are what aren't fine.

You're right, in that the existing mechanisms *can* deal with the
issues. However, two of the points that comes up over and over again
here is "use parameters, don't build the query strings yourself" and
"we would rather the module authors do the work than the users". I'm
trying to figure out how *either* of those is miscible with "Just use
pythons string substitutions for table/column names", much less *both*
of them.

   <mike
-- 
Mike Meyer <mwm at mired.org>		http://www.mired.org/consulting.html
Independent Network/Unix/Perforce consultant, email for more information.