[DB-SIG] paramstyles, again (and now voting)

Carsten Haese carsten at uniqsys.com
Thu Jun 21 14:51:31 CEST 2007


On Thu, 2007-06-21 at 07:31 -0500, Carl Karsten wrote:
> Carsten Haese wrote:
> > The advantages are clear:
> > 
> > * Application code written against this spec can be sure that named/qmark
> > styles are available, and there is a common API for choosing which one to use.
> > That means less API dependent code, and the overhead for choosing qmark or
> > named is minimal at one line of code per connection.
> > 
> > * APIs aren't forced to abandon "legacy" parameter styles so existing code
> > written for existing APIs won't break.
> > 
> > * No backwards compatibility wrapper is necessary.
> 
> I do not see the last 2 points as a clear advantage, given the cost.

What cost? The one line of code per connection to explicitly choose
qmark or named style?

And since when is compatibility with existing code not an advantage?

> > 
> > You're welcome to try to come up with a simpler solution that has the same
> > advantages.
> 
> I did before: "only allow one style of parameter."  But it got out voted, (or 
> not even on the ballot) and so I won't push for it anymore.
>
>   >>> numeric -1
>   >>> format -5
>   >>> pyformat -2
> 
> To me that reads "remove them."  0 would have been "tolerate them."

Then you misunderstood the point of the vote. We voted on which
paramstyle should be required, not which paramstyles should exist at
all. We could have a separate vote on which parameter styles to
deprecate, and I bet a lot of people would want to remove format and
pyformat. However, there is a lot of MySQL and PostgreSQL code out there
that would break if those styles were removed outright.

> However, I can see that if there was at least one parmstyle that was consistent 
> across all APIs (like we are all in agreement on), no one in their right mind 
> would use one of the non-standard ones.

Indeed. The practical benefit comes from having common ground to stand
on. There is no practical benefit in breaking backwards compatibility by
forcing everybody onto this common ground.

-- 
Carsten Haese
http://informixdb.sourceforge.net




More information about the DB-SIG mailing list