[Dbix-class] "having" attribute problems with SQLite

[Will Hawes]

The 0.08010 docs in DBIx::Class::ResultSet contain an example for the
"having" attribute that shows parameter values being passed using a
hashref:

having => { 'count(employee)' => { '>=', 100 } }

Meanwhile, in the test suite there are a couple of tests using
"having" (76joins.t in 0.08010 and 77prefetch.t in 0.08 trunk), but
these both pass a scalar ref instead, like this:

$rs = $rs->search( undef, {  having =>{ 'count(*)'=> \'> 2' }});

DBIC_TRACE shows the following SQL is generated for the above test:

SELECT me.artistid, me.name FROM artist me LEFT JOIN cd cds ON (
cds.artist = me.artistid ) GROUP BY me.name HAVING ( ( ( MAX(cds.cdid)
< 5 ) AND ( count(*) > 2 ) ) ):

And here's what happens if the test is altered to use the hashref syntax:

$rs = $rs->search( undef, {  having =>{ 'count(*)'=> { '>', 2' }}});

SELECT me.artistid, me.name FROM artist me LEFT JOIN cd cds ON (
cds.artist = me.artistid ) GROUP BY me.name HAVING ( ( ( MAX(cds.cdid)
< 5 ) AND ( count(*) > ? ) ) ): '2'

Both look fine to me and I'm not getting any errors, but I'm seeing
the scalarref syntax return rows as expected, while the hashref syntax
returns zero rows irrespective of what's in the database.

I've observed this on two machines, one running DBD::SQLite 1.14 and
DBI 1.607 and the other DBD::SQLite 1.13 and DBI 1.57.

I don't have a database server handy to test against other drivers
atm, but since DBIx::Class::Storage::DBI calls $sth->bind_param when
the hashref syntax is used I'm guessing the DBIC docs are correct and
that this may be a DBD problem of some sort.

I've not found reference to anything similar in the list archives -
can anyone else confirm this behaviour before I go any further?