On Oct 14, 11:29 am, Carsten Haese <cars...@uniqsys.com> wrote:
> On Sun, 2007-10-14 at 16:10 +0000, Gerardo Santana wrote:
> > I want to know how to reproduce it in order to know if Ruby/Informix
> > is affected.
>
> > The previous query worked as expected with Informix 11, CSDK 2.90 and
> > Ruby/Informix. But maybe I'm missing something.
>
> I've taken a quick look at your code, and it is indeed not affected by
> this bug, but it has another bit of surprising behavior. You simply bind
> True as the string 't' and False as the string 'f'. That works well
> enough if you only ever bind True and False to Boolean columns. However,
> users of older engines might want to bind a boolean value to a numeric
> column (int/smallint), in which case your binding will fail.


Ok, fair enough.
I'll keep that behavior, since in Ruby land there's no numeric
interpretation for true or false.


>
> My code takes a different approach. It interprets True as 1 and False as
> 0, so that they can be bound to numeric columns, and when the
> destination is a boolean, the input parameter is bound as an actual
> SQLBOOL. That requires knowing the type of the destination, which was
> easy enough to obtain with DESCRIBE for INSERT and UPDATE statements,
> and those have worked for a while. However, for SELECT statements, my
> approach requires a DESCRIBE INPUT step, which wasn't done until now.


I see. Informix itself doesn't provide a cast from integer to boolean.
I think I will keep that too.

>
> Another advantage of knowing the destination type is that it allows
> Python's duck-typing semantics: you can bind any object, not just
> True/False to a boolean column. If an arbitrary object is bound to a
> boolean column, it's automatically cast into a bool first.
>
> Whether you need to do any of this depends on what your users expect.
> What my module does is "Pythonic". I don't know what "Rubyic" behavior
> requires

Certainly

Thank you for the explanation!

--
Gerardo