Python 3.1 support
in [PgSql]
|
Prev: New VACUUM FULL
Next: Aggregate ORDER BY patch
From: Tino Wildenhain on 20 Nov 2009 04:30 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: Peter Eisentraut on 10 Dec 2009 18:19 On tor, 2009-11-12 at 16:06 -0500, Tom Lane wrote: > There was considerable debate earlier about whether we wanted to treat > Python 3 as a separate PL so it could be available in parallel with > plpython 2, because of the user-level coding incompatibilities. It > looks like this patch simply ignores that problem. What is going to > happen to plpython functions that depend on 2.x behavior? I have a proposal for how to handle this, and a prototype patch attached. This follows essentially what the CPython distribution itself does, which will make this tolerably easy to follow for users. We install plpython as plpython2.so or plpython3.so, depending on the version used to build it. Then, plpython.so is a symlink to plpython2.so. We then create three language definition templates: plpythonu -> plpython.so plpython2u -> plpython2.so plpython3u -> plpython3.so In the far future we flip the default symlink to plpython3.so, maybe in about 5 years when Python 2.x expires. This gives the users the following options and scenarios: - Existing users don't have to do anything, until maybe in five years they will notice that their OS doesn't ship Python 2 anymore and they will have to act anyway. In practice, by then they might have adjusted their coding style to Python 2.6/2.7 norms and their functions will migrate to 3.x without change. - Users who know that they have heavily Python 2.x dependent code and don't want to ever change it can make use of the plpython2u language name, just like they should probably change their scripts to use something like #!/usr/bin/python2. - Users who want to dive into Python 3 can use the plpython3u language name, which will basically keep working forever by today's standards. Those users would probably also use #!/usr/bin/python3 or the like in their scripts. In the far future they might like to remove the "3". - Daredevils can change symlink manually and make plpython3.so the default plpythonu implementation. Those people would probably also make /usr/bin/python be version 3. Comments?
From: "Joshua D. Drake" on 11 Dec 2009 12:59 On Fri, 2009-12-11 at 01:19 +0200, Peter Eisentraut wrote: > On tor, 2009-11-12 at 16:06 -0500, Tom Lane wrote: > > There was considerable debate earlier about whether we wanted to treat > > Python 3 as a separate PL so it could be available in parallel with > > plpython 2, because of the user-level coding incompatibilities. It > > looks like this patch simply ignores that problem. What is going to > > happen to plpython functions that depend on 2.x behavior? > > I have a proposal for how to handle this, and a prototype patch > attached. This follows essentially what the CPython distribution itself > does, which will make this tolerably easy to follow for users. > > We install plpython as plpython2.so or plpython3.so, depending on the > version used to build it. Then, plpython.so is a symlink to > plpython2.so. > > We then create three language definition templates: > > plpythonu -> plpython.so > plpython2u -> plpython2.so > plpython3u -> plpython3.so > > > Comments? Well as a Python guy... makes sense to me :) Joshua D. Drake -- PostgreSQL.org Major Contributor Command Prompt, Inc: http://www.commandprompt.com/ - 503.667.4564 Consulting, Training, Support, Custom Development, Engineering If the world pushes look it in the eye and GRR. Then push back harder. - Salamander -- Sent via pgsql-hackers mailing list (pgsql-hackers(a)postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
From: Peter Eisentraut on 14 Dec 2009 13:42 I wrote: > On tor, 2009-11-12 at 16:06 -0500, Tom Lane wrote: > > There was considerable debate earlier about whether we wanted to treat > > Python 3 as a separate PL so it could be available in parallel with > > plpython 2, because of the user-level coding incompatibilities. It > > looks like this patch simply ignores that problem. What is going to > > happen to plpython functions that depend on 2.x behavior? > > I have a proposal for how to handle this, and a prototype patch > attached. This follows essentially what the CPython distribution itself > does, which will make this tolerably easy to follow for users. > > We install plpython as plpython2.so or plpython3.so, depending on the > version used to build it. Then, plpython.so is a symlink to > plpython2.so. So here is the potentially final patch for this, including the original port of plpython.c itself, build system adjustments, and documentation. -- Sent via pgsql-hackers mailing list (pgsql-hackers(a)postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
From: Robert Haas on 14 Dec 2009 13:47
On Mon, Dec 14, 2009 at 1:42 PM, Peter Eisentraut <peter_e(a)gmx.net> wrote: > I wrote: >> On tor, 2009-11-12 at 16:06 -0500, Tom Lane wrote: >> > There was considerable debate earlier about whether we wanted to treat >> > Python 3 as a separate PL so it could be available in parallel with >> > plpython 2, because of the user-level coding incompatibilities. It >> > looks like this patch simply ignores that problem. What is going to >> > happen to plpython functions that depend on 2.x behavior? >> >> I have a proposal for how to handle this, and a prototype patch >> attached. This follows essentially what the CPython distribution itself >> does, which will make this tolerably easy to follow for users. >> >> We install plpython as plpython2.so or plpython3.so, depending on the >> version used to build it. Then, plpython.so is a symlink to >> plpython2.so. > > So here is the potentially final patch for this, including the original > port of plpython.c itself, build system adjustments, and documentation. I think you forgot to actually attach it... ....Robert -- Sent via pgsql-hackers mailing list (pgsql-hackers(a)postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers |