It looks like it can't convert a record to a tuple. Composite type
mapping that was added in 2.4 might work. Perhaps it is time to file a
bug?
You could try this:
psycopg2.extras.register_composite('record',globally=True)
I have not tested since I don't have the latest (2.4) installed.
On Thu, Mar 31, 2011 at 1:59 PM, Mark McWiggins
<[email protected]> wrote:
>
>
> On Thu, Mar 31, 2011 at 1:00 PM, Mike Orr <[email protected]> wrote:
>>
>> Why are you putting () around the fields? Is that even legal in SQL
>> for a SELECT field list?
>
> Yes it's legal.
>
>>
>> It sounds like you're dismissing libraries
>> because of a few uncommon edge cases. Which makes me wonder if your
>> main goal is to pass judgement on the libraries rather than finding
>> something that'll work good enough in an application.
>
> I didn't dismiss them; I was under a tight time limit and found finally that
> psycopg v1
> worked just well enough to use for the application.
>
>>
>> You can always file a bug report if you think the library is
>> incorrect, or search the library's mailing list to see if it has been
>> reported before and what the developers' attitude is.
>>
>
> Yes, I will do that next week after I set up some simple cases that show the
> bugs. Some of this seems to only occur with large numbers of fields, but
> that's
> what I have to deal with in this application.
>
>>
>> On Thu, Mar 31, 2011 at 12:48 PM, Mark McWiggins
>> <[email protected]> wrote:
>> > It may work if coded carefully around its bugs. The most egregious
>> > example I
>> > found was that instead of
>> > returning a tuple with the field values expected after doing
>> > SELECT (field1, field2, field3) from table
>> > it returns the STRING with those fields in it, for example
>> > '(8,"just a second, dammit",9)'
>> > that has to be unpacked programmatically. This happens in both psycopg
>> > and
>> > psycopg2.
>>
>>
>> --
>> Mike Orr <[email protected]>
>>
>
>
>
> --
> Mark McWiggins
> 425-369-8286 (cell)
>
