Re: #186: registering/using converters

Hey, I'm the original submitter of this bug.  I haven't seen a response
to this yet, and was wondering if anyone has looked at it.  Would it be
addressed faster if I submitted a patch?  Thanks.

Glenn

On Sat, 16 Dec 2006 21:03:17 -0000
"pysqlite" <trac-NGVKUo/i/[email protected]> wrote:

> #186: registering/using converters
> ----------------------------+-----------------------------------------------
>  Reporter:  crass           |       Owner:  gh 
>      Type:  defect          |      Status:  new
>  Priority:  medium          |   Milestone:     
> Component:  Implementation  |     Version:  SVN
>  Severity:  serious         |    Keywords:     
> ----------------------------+-----------------------------------------------
>  The C code to register converters converts the converter name to
> upper case using an algorithm that only sanely works on letters
> (A-Za-z), but gives bad results for punctuation and other nonletter
> characters.  I propose that this code either use the libc toupper or
> convert to a python string and call the upper method.
> 
>  Likewise, a converter for VARCHAR won't apply to VARCHAR(20) (even
>  assuming the above it fixed).  Since the key for getting the
> converter is based on an exact match or up until the first space of
> the type name string.  So, while VARCHAR and VARCHAR(20) won't
> trigger the same converter, VARCHAR and "VARCHAR (20)" will (though
> I'm not sure that will get past the sql parser).  I think intuitively
> people expect all those to be the same type class.  I propose that
> multiple lookups are done on the converters dict.  First do an exact
> match (case insensitive as it already is of course).  If that key is
> not found, parse the type such that the longest type name that is
> valid under the sql spec starting from the beginning of the type
> string be lookedup.
> 
>  I can write a patch for this if desired (though I don't know what
> the spec says about valid type name identifiers).
>