| From: | James Pye <lists(at)jwp(dot)name> |
|---|---|
| To: | Peter Eisentraut <peter_e(at)gmx(dot)net> |
| Cc: | Nathan Boley <npboley(at)gmail(dot)com>, pgsql-hackers(at)postgresql(dot)org |
| Subject: | Re: Python 3.1 support |
| Date: | 2009-11-19 17:01:48 |
| Message-ID: | 2A71238A-F32A-4774-957E-383B63676F7A@jwp.name |
| Views: | Whole Thread | Raw Message | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-hackers |
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?
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.
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Florian G. Pflug | 2009-11-19 17:43:17 | Re: Listen / Notify - what to do when the queue is full |
| Previous Message | Kevin Grittner | 2009-11-19 16:55:24 | Re: Timezones (in 8.5?) |