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

Carsten Haese carsten at uniqsys.com
Thu Jun 21 06:38:25 CEST 2007


On Wed, 20 Jun 2007 22:59:18 -0500, Carl Karsten wrote
> "super simple" would be the new api.   pretty easy is the wrapper 
> for backwards computability.
> 
> As complex as that set would be, it wouldn't be much worse than the 
> current mess.

That's why we're discussing an improvement. The current proposal on the table
is this:

* Every API implements at least qmark and named.

* APIs are allowed to implement other styles.

* Connection and Cursor objects have a writable paramstyle attribute to choose
which paramstyle to use. The default is implementation-defined. Possible
settings are implementation-defined but must include at least qmark and named.

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.

You're welcome to try to come up with a simpler solution that has the same
advantages.

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



More information about the DB-SIG mailing list