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 _______________________________________________ DB-SIG maillist - DB-SIG@python.org http://mail.python.org/mailman/listinfo/db-sig
