Re: Are there Sql backends that return an array from big_query()?

H. William Welliver III wrote:
>Will there be compatibility glue for those who???ve worked with the
> current system? I know of a more than a few cases that would be affected
> by this change??? (such as direct access to master_sql, etc).

Well, actually, the only real incompatibility would be reference to master_sql
which is not needed anymore.  But it's easy to still keep
it around for real or in compat using a plain reference to "this".

>Would this change be committed to 8.0 or 8.1?

8.1, there is no need to commit it to 8.0.  It's merely a code cleanup
which results in better structure, less overhead and slightly enhanced
speed (contrary to the new pgsql driver, which fixes real bugs in the
old one, so I intend to backport it to 8.0 once stabilised).

>> Erm, yes, KISS.  All the Sql.pmod/*.pike files could simply be
>> made to inherit the Sql.SQL class.  This is possible at the pike
>> level (obviously).  Well, that makes the change rather trivial.
>> In fact so trivial that it almost seems like I must be overlooking
>> something; we could have done this 10 years ago.

Well, as it seems, Sql.Sql()->big_query(), accepts sprintf like
arguments.  The real backend's big_query() only accepts bindings
(usually), so there is going to be some minimal wrapping anyway,
which (in turn) means that I can still accomodate for the array
return object as well.  It also means that I'll provide for some
kind of "raw_query()" method which calls the underlying backend
big_query() without wrapping.
-- 
Stephen.