From: | Tino Wildenhain <tino(at)wildenhain(dot)de> |
---|---|
To: | pgsql-hackers(at)postgresql(dot)org |
Subject: | Re: Python 3.1 support |
Date: | 2009-11-20 09:30:05 |
Message-ID: | 4B06619D.7050802@wildenhain.de |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
Am 19.11.2009 18:01, schrieb James Pye:
> On Nov 19, 2009, at 3:12 AM, Peter Eisentraut wrote:
>> The other approach, which is what James Pye's
>> new implementation proposes (as I understand it), is to convert
>> PostgreSQL types into specially made Python objects, such as
>> Postgres.types.record or Postgres.types.timestamp.
>
> Convert is not a good word choice. The Datum of the parameter is stored inside a new Python object(that only holds a Datum). So more like "copied into Python memory", and associated with its respective type. Wrapped in a Python object?
Yes "wrapped" is the term commonly used for that. And I must say I like
it and I used plpy where I could.
> One cool thing about doing it this way, is that if you just pass parameters forward to a prepared statement, there's no type I/O overhead. Not a huge performance win for common cases, but if someone were passing larger arrays around, it could be quite beneficial.
Exactly and you have all the meta information about the original
postgres type. IIRC there were some thoughts of having something like
that in a DBAPI interface as well (similar for example to cx_Oracle).
Tino
From | Date | Subject | |
---|---|---|---|
Next Message | Joachim Wieland | 2009-11-20 09:35:46 | Re: Listen / Notify - what to do when the queue is full |
Previous Message | James Pye | 2009-11-20 08:59:56 | Re: Python 3.1 support |