True, but the code that handles that case isn't very complex, so why create a potential compat problem? What's the benefit?
Bill
> On Oct 30, 2014, at 6:25 AM, Stephen R. van den Berg <srb(a)cuci.nl> wrote:
>
> But the official one doesn't do that anymore, I think.
>
> Just trying to chart how many of the builtin backends actually still need the Sql.sql_array_result. And if so, they should need to wrap it themselves by providing a big_query which already returns the wrapped version instead of relying on the Sql glue to fix it afterward.
>
>> On Thu, Oct 30, 2014 at 3:40 AM, H. William Welliver III <bill(a)welliver.org> wrote:
>> I wrote a backend for SQLite (back before the official one existed) that did this; actually it retrieved the result as an array and then created a Sql.sql_array_result object with it as the argument to create(). I suspect that’s similar to what the code you refer to is doing.
>>
>> Bill
>>
>> > On Oct 29, 2014, at 10:05 PM, Stephen R. van den Berg <srb(a)cuci.nl> wrote:
>> >
>> > Looking at ways to streamline the Sql.Sql interface, I find that
>> > there is code in the current big_query() to handle the case when
>> > the return value of the real sql backend big_query() happens to be
>> > an array instead of a genuine object, it puts a wrapper function around it.
>> >
>> > Are there currently any SQL backends which actually return an array from
>> > big_query()?
>> > --
>> > Stephen.
>
>
>
> --
> Stephen.