[DB-SIG] Fetch_raw

[Carsten Haese]

On Wed, 2007-05-02 at 08:47 -0400, Art Protin wrote:
> [...]I find that there is
> some merit in getting the data, any of the data, as strings, which just
> happens to be the format that our database uses to pass them.
> Thus, there are two aspects where you could now influence my
> implementation:
> 
> 1) any of you could argue that it is a corruption of the API that will
> lead to bad results or bad practices to include a mechanism for accessing
> the "raw" data;  OR

I'm not going to argue that. Allowing access to "raw" data may be
beneficial for performance and meaningful to the developer. For example,
my InformixDB module allows retrieving values of User-Defined Types in
binary form. I think this is perfectly acceptable as long as the
developers are consenting adults who know what to do with the raw data
and understand that they're welding their application to a particular
database and API implementation.

> 2) any of you could argue about the form that such an extension should
> take.

And we will ;)

>     I am torn between adding an additional optional parameter to the
> methods .fetchone(), .fetchmany(), and .fetchall(),  and adding three
> new methods: .fetch_one_raw(), .fetch_many_raw() and .fetch_all_raw().

Adding an optional parameter is in my opinion way better than making
three new methods. Alternatively or additionally, you could add an
attribute to the cursor object for controlling how fetch results are
returned.

-Carsten