From: | Peter Eisentraut <peter_e(at)gmx(dot)net> |
---|---|
To: | Nathan Boley <npboley(at)gmail(dot)com> |
Cc: | James Pye <lists(at)jwp(dot)name>, pgsql-hackers(at)postgresql(dot)org |
Subject: | Re: Python 3.1 support |
Date: | 2009-11-19 10:12:28 |
Message-ID: | 1258625548.21292.13.camel@fsopti579.F-Secure.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
On ons, 2009-11-18 at 08:43 -0800, Nathan Boley wrote:
> > Again, I'm only one user. But so far I haven't seen anyone else speak
> > up here, and clearly accepting this for inclusion will need nontrivial
> > convincing.
>
> Well, FWIW, I am excited about better type integration.
Let's clarify, as there are two different models being proposed here.
The first approach, which is currently implemented (and some patches
pending), is to convert a PostgreSQL type to the "nearest" Python type.
For example, text to string, int to int, array to list, timestamp to
datetime.datetime, etc. 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.
> Also, I am a little skeptical about this patch. I am sorry if this has
> already been discussed, but would this mean that I need to choose
> whether pl/python is built against Python 2.* or Python 3.*?
Yeah, see later discussion about how to resolve this. But I think in
practice, unless you use lots of print statements in your stored
procedures (?!?), this problem is exaggerated.
From | Date | Subject | |
---|---|---|---|
Next Message | Peter Eisentraut | 2009-11-19 12:00:51 | Re: Python 3.1 support |
Previous Message | Peter Eisentraut | 2009-11-19 10:05:42 | Re: Python 3.1 support |