Re: [HACKERS] Python 3.x versus PG 9.1 branch

On Wed, Jan 13, 2016 at 11:46 AM, Tom Lane wrote: > Or we could just blow it off on the grounds that 9.1 is not long > for this world anyhow. +1 for blowing it off. I can't see the point in putting effort into this. Nobody should be spinning up new PostgreSQL 9.1

Re: [HACKERS] Python 3.x versus PG 9.1 branch

On Thu, Jan 14, 2016 at 12:37 PM, Noah Misch wrote: > On Wed, Jan 13, 2016 at 11:46:07AM -0500, Tom Lane wrote: >> [...] we've repeatedly not bothered >> to back-port regression test fixes for newer Pythons into that branch. >> I could just omit Python 3 coverage for that

Re: [HACKERS] Python 3.x versus PG 9.1 branch

On Wed, Jan 13, 2016 at 11:46:07AM -0500, Tom Lane wrote: > [...] we've repeatedly not bothered > to back-port regression test fixes for newer Pythons into that branch. > I could just omit Python 3 coverage for that branch in the critter's > configuration, but I wonder exactly why things are that

[HACKERS] Python 3.x versus PG 9.1 branch

In view of our rather embarrassing failure to cover the back branches with Python 3.5-related regression test adjustments, I think there is a clear need for a buildfarm critter that's testing with Python 3.5, and I've been working on setting one up. It's passing at the moment for 9.2 and up, but

Re: [HACKERS] Python 3 compatibility fun

On 11/11/15 1:49 PM, Tom Lane wrote: > Peter Eisentraut writes: >> On 11/11/15 12:08 PM, Tom Lane wrote: >>> we're failing to build against Python 3.5 because the python guys >>> have randomly changed some error message texts, again. > >> This has already been fixed in the 9.5.

[HACKERS] Python 3 compatibility fun

According to https://bugzilla.redhat.com/show_bug.cgi?id=1280404 we're failing to build against Python 3.5 because the python guys have randomly changed some error message texts, again. In the short run the answer must be to add some more variant expected-files, but I wonder if we should be

Re: [HACKERS] Python 3 compatibility fun

On 11/11/15 12:08 PM, Tom Lane wrote: > we're failing to build against Python 3.5 because the python guys > have randomly changed some error message texts, again. This has already been fixed in the 9.5. -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to

Re: [HACKERS] Python 3 compatibility fun

Peter Eisentraut writes: > On 11/11/15 12:08 PM, Tom Lane wrote: >> we're failing to build against Python 3.5 because the python guys >> have randomly changed some error message texts, again. > This has already been fixed in the 9.5. Well, that's nice, but surely it should have

[HACKERS] python modul pre-import to avoid importing each time

Hey List, this is a repost from the general list where it get no responses (5 days) I use plpython with postgis and 2 python modules (numpy and shapely). Sadly importing such module in the plpython function is very slow (about half a second). I also don't know if this overhead is applied each

[HACKERS] Python version dependency in plpython regression tests

After reading the recent thread about python 2 vs python 3 support, I thought I'd amuse myself by trying to get plpython3 supported in the Fedora packages. That turned out to be unreasonably painful (which is something we oughta fix eventually), but it worked, at least with F16/F17. When I went

Re: [HACKERS] Python version dependency in plpython regression tests

On Sat, 2012-09-08 at 16:35 -0400, Tom Lane wrote: and obviously, python is iterating through the hash's keys in a different order than it was a minor version or two back. (The failure is occurring with 3.3.0-0.4.rc1.fc19, whereas I saw no failure with 3.2.3-7.fc17.) Yes, known problem with

Re: [HACKERS] Python version dependency in plpython regression tests

Peter Eisentraut pete...@gmx.net writes: On Sat, 2012-09-08 at 16:35 -0400, Tom Lane wrote: I think probably the best thing is to change the test case so it has one valid key and one not-valid one, rather than assuming that the same key will always be complained of when there's more than one

Re: [HACKERS] Python version dependency in plpython regression tests

On Sat, 2012-09-08 at 16:52 -0400, Tom Lane wrote: How come you did not back-patch that commit ... are we not supporting 3.3 in branches before 9.2 for some reason? Python 3.3 isn't even released yet, much less so back then, so it seemed premature. Also, it's a fairly big change just to make

Re: [HACKERS] python cleanup

On 07/25/2011 12:03 PM, Tom Lane wrote: Andrew Dunstanand...@dunslane.net writes: On 07/25/2011 10:52 AM, Tom Lane wrote: What is features.h, and have its authors read the POSIX standard? AFAICS they have no business defining this symbol. [andrew@emma ~]$ rpm -q -f

Re: [HACKERS] python cleanup

On 07/24/2011 11:46 PM, Tom Lane wrote: [python headers set _POSIX_C_SOURCE and _XOPEN_SOURCE] What in the world are the python headers doing fooling with these macros, anyway?? Good question. It seems unfriendly. It looks like you're just about guaranteed to get a warning if you include

Re: [HACKERS] python cleanup

Andrew Dunstan and...@dunslane.net writes: On 07/24/2011 11:46 PM, Tom Lane wrote: [python headers set _POSIX_C_SOURCE and _XOPEN_SOURCE] What in the world are the python headers doing fooling with these macros, anyway?? The reason we get warnings about these and not about many other things

Re: [HACKERS] python cleanup

Andrew Dunstan and...@dunslane.net writes: [python headers set _POSIX_C_SOURCE and _XOPEN_SOURCE] BTW ... so far as I can find, there is no attempt anywhere in the Postgres sources to set either of these macros. And my understanding of their purpose is that *system* headers should not be

Re: [HACKERS] python cleanup

On 07/25/2011 10:36 AM, Tom Lane wrote: Andrew Dunstanand...@dunslane.net writes: [python headers set _POSIX_C_SOURCE and _XOPEN_SOURCE] BTW ... so far as I can find, there is no attempt anywhere in the Postgres sources to set either of these macros. And my understanding of their purpose

Re: [HACKERS] python cleanup

Andrew Dunstan and...@dunslane.net writes: On 07/25/2011 10:36 AM, Tom Lane wrote: Andrew Dunstanand...@dunslane.net writes: [python headers set _POSIX_C_SOURCE and _XOPEN_SOURCE] BTW ... so far as I can find, there is no attempt anywhere in the Postgres sources to set either of these

Re: [HACKERS] python cleanup

On 07/25/2011 10:52 AM, Tom Lane wrote: Andrew Dunstanand...@dunslane.net writes: On 07/25/2011 10:36 AM, Tom Lane wrote: Andrew Dunstanand...@dunslane.net writes: [python headers set _POSIX_C_SOURCE and _XOPEN_SOURCE] BTW ... so far as I can find, there is no attempt anywhere in the

Re: [HACKERS] python cleanup

Andrew Dunstan and...@dunslane.net writes: On 07/25/2011 10:52 AM, Tom Lane wrote: What is features.h, and have its authors read the POSIX standard? AFAICS they have no business defining this symbol. [andrew@emma ~]$ rpm -q -f /usr/include/features.h glibc-headers-2.13-1.x86_64 Oh,

[HACKERS] python cleanup

On 04/24/2011 07:31 PM, Peter Eisentraut wrote: On sön, 2011-04-24 at 12:25 -0400, Tom Lane wrote: This file is in fundamental violation of the first commandment of Postgres #includes, which is thou shalt have no other gods before c.h. We need to put postgres.h *before* the Python.h include.

Re: [HACKERS] python cleanup

Andrew Dunstan and...@dunslane.net writes: On my Linux system the attached compiles without warnings. If this seems like the way to go I'll investigate more on Windows. Hmm ... +/* + * Save settings the Python headers might override + */ +#ifdef _POSIX_C_SOURCE +#define

Re: [HACKERS] Python 2.7 deprecated the PyCObject API?

On tis, 2010-08-17 at 21:48 +0300, Peter Eisentraut wrote: On tis, 2010-08-17 at 20:55 +0300, Peter Eisentraut wrote: On fre, 2010-08-13 at 20:20 -0400, Tom Lane wrote: According to a discussion over in Fedora-land, $subject is true:

Re: [HACKERS] Python 2.7 deprecated the PyCObject API?

On fre, 2010-08-13 at 20:20 -0400, Tom Lane wrote: According to a discussion over in Fedora-land, $subject is true: http://lists.fedoraproject.org/pipermail/devel/2010-August/140995.html I see several calls in plpython.c that seem to refer to PyCObject stuff. Anybody have any idea if we

Re: [HACKERS] Python 2.7 deprecated the PyCObject API?

On tis, 2010-08-17 at 20:55 +0300, Peter Eisentraut wrote: On fre, 2010-08-13 at 20:20 -0400, Tom Lane wrote: According to a discussion over in Fedora-land, $subject is true: http://lists.fedoraproject.org/pipermail/devel/2010-August/140995.html I see several calls in plpython.c that

Re: [HACKERS] Python 2.7 deprecated the PyCObject API?

James William Pye li...@jwp.name writes: On Aug 14, 2010, at 9:08 AM, Tom Lane wrote: Just to clarify, you're recommending something like proc-me = PyCObject_FromVoidPtr(proc, NULL); +if (proc-me == NULL) +elog(ERROR, could not create PyCObject

Re: [HACKERS] Python 2.7 deprecated the PyCObject API?

James William Pye li...@jwp.name writes: On Aug 13, 2010, at 5:20 PM, Tom Lane wrote: I see several calls in plpython.c that seem to refer to PyCObject stuff. Anybody have any idea if we need to do something about this? Well, we should at least be checking for an exception here anyways:

Re: [HACKERS] Python 2.7 deprecated the PyCObject API?

On Aug 14, 2010, at 9:08 AM, Tom Lane wrote: Just to clarify, you're recommending something like proc-me = PyCObject_FromVoidPtr(proc, NULL); + if (proc-me == NULL) + elog(ERROR, could not create PyCObject for function);

[HACKERS] Python 2.7 deprecated the PyCObject API?

According to a discussion over in Fedora-land, $subject is true: http://lists.fedoraproject.org/pipermail/devel/2010-August/140995.html I see several calls in plpython.c that seem to refer to PyCObject stuff. Anybody have any idea if we need to do something about this?

Re: [HACKERS] Python 2.7 deprecated the PyCObject API?

On Aug 13, 2010, at 5:20 PM, Tom Lane wrote: According to a discussion over in Fedora-land, $subject is true: http://lists.fedoraproject.org/pipermail/devel/2010-August/140995.html I see several calls in plpython.c that seem to refer to PyCObject stuff. Anybody have any idea if we need to do

[HACKERS] Python Interface Hacking

Hi all, I joined this list under the mis-impression that it was about hacking the Python interfaces to pgsql. Is there possibly another list for that? Or is the Python stuff just mixed in with all the rest? Sorry for the meta-question... Cheers, Peter -- Peter H. Froehlich

Re: [HACKERS] Python Interface Hacking

On Wed, Jul 7, 2010 at 3:07 AM, Peter Froehlich peter.hans.froehl...@gmail.com wrote: I joined this list under the mis-impression that it was about hacking the Python interfaces to pgsql. Is there possibly another list for that? Or is the Python stuff just mixed in with all the rest? Sorry for

Re: [HACKERS] Python Interface Hacking

On ons, 2010-07-07 at 03:07 -0400, Peter Froehlich wrote: I joined this list under the mis-impression that it was about hacking the Python interfaces to pgsql. Is there possibly another list for that? Or is the Python stuff just mixed in with all the rest? Sorry for the meta-question... If

Re: [HACKERS] Python Interface Hacking

On Wed, Jul 7, 2010 at 8:49 AM, Peter Eisentraut pete...@gmx.net wrote: If you want to hack PL/Python, which is a Python interpreter embedded into the PostgreSQL server, then this is the right place.  (Yes, it's mixed with all the rest.) If you want to hack a Python client driver, then go to

Re: [HACKERS] Python Interface Hacking

On 07/07/10 17:19, Peter Froehlich wrote: On Wed, Jul 7, 2010 at 8:49 AM, Peter Eisentrautpete...@gmx.net wrote: If you want to hack PL/Python, which is a Python interpreter embedded into the PostgreSQL server, then this is the right place. (Yes, it's mixed with all the rest.) If you want to

Re: [HACKERS] Python Interface Hacking

On Jul 7, 2010, at 12:07 AM, Peter Froehlich wrote: I joined this list under the mis-impression that it was about hacking the Python interfaces to pgsql. Is there possibly another list for that? Or is the Python stuff just mixed in with all the rest? Sorry for the meta-question... For BSD/MIT

Re: [HACKERS] Python 3.1 support

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

Re: [HACKERS] Python 3.1 support

On Mon, Dec 14, 2009 at 1:42 PM, Peter Eisentraut pete...@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,

Re: [HACKERS] Python 3.1 support

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

Re: [HACKERS] Python 3.1 support

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

Re: [HACKERS] Python 3.1 support

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

Re: [HACKERS] Python 3.1 support

On Nov 20, 2009, at 12:02 AM, Peter Eisentraut wrote: Is there any precedent for the sort of behavior that you are implementing, that is, automatic sharing of variables between independent executions of the same source container? import foo # bar is a regular, def'd function. foo.bar() ...

Re: [HACKERS] Python 3.1 support

On fre, 2009-11-20 at 01:20 -0700, James Pye wrote: On Nov 20, 2009, at 12:02 AM, Peter Eisentraut wrote: Is there any precedent for the sort of behavior that you are implementing, that is, automatic sharing of variables between independent executions of the same source container? import

Re: [HACKERS] Python 3.1 support

On Nov 20, 2009, at 1:26 AM, Peter Eisentraut wrote: because this is the same execution Hrm, not necessarily. foo could be imported by another, completely independent part of the program. foo is cached in sys.modules. bar() is executed and it's still the same globals(). shared. -- Sent via

Re: [HACKERS] Python 3.1 support

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

Re: [HACKERS] Python 3.1 support

On ons, 2009-11-18 at 09:48 -0800, Joshua D. Drake wrote: Although I wonder if longer term (2.x is going to be support a long time) we will end up with frustration within the single source file trying to keep things straight. There are five million Python modules with C code out there with

Re: [HACKERS] Python 3.1 support

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

Re: [HACKERS] Python 3.1 support

On ons, 2009-11-18 at 11:32 -0800, Nathan Boley wrote: I took a cursory look at this patch and, while the logic seems sound and roughly in line with the suggested python porting procedure, I'm not quite certain what this implies for potential future patches. For instance, if I wanted to

Re: [HACKERS] Python 3.1 support

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

Re: [HACKERS] Python 3.1 support

On ons, 2009-11-18 at 12:28 -0500, Tom Lane wrote: Joshua D. Drake j...@commandprompt.com writes: On Wed, 2009-11-18 at 12:06 -0500, Tom Lane wrote: Yes. That's exactly what I was complaining about upthread. I'm not a Python user, but from what I can gather of the 2-to-3 changes, having

Re: [HACKERS] Python 3.1 support

On ons, 2009-11-18 at 13:36 -0700, James Pye wrote: On Nov 18, 2009, at 8:37 AM, Peter Eisentraut wrote: The question is whether it helps the user, not the implementer. Sure, but do you have a patch waiting to implement tracebacks? I'd argue the reason it's never been done is due to the

Re: [HACKERS] Python 3.1 support

Peter Eisentraut pete...@gmx.net writes: By the way, it occurred to me that having two different versions of libpython loaded into the same process is probably not going to work sanely. Why not? There's no way they'd even know about each other. We tell the loader not to make the symbols

Re: [HACKERS] Python 3.1 support

On Nov 19, 2009, at 11:32 AM, Peter Eisentraut wrote: But you wouldn't, for example, get away with breaking SQL (or even improving it incompatibly) to facilitate a better elog. This doesn't fit the situation. I'm not breaking PL/Python. I'm trying to add PL/Python3. =) I think of a PL/Python

Re: [HACKERS] Python 3.1 support

On tor, 2009-11-19 at 13:43 -0500, Tom Lane wrote: But in any case, my main concern here is that I don't want to have to predetermine which python version a user of Red Hat/Fedora will have to use. If they can only use one at a time, that's still a good bit better than not having a choice at

Re: [HACKERS] Python 3.1 support

On tor, 2009-11-19 at 13:12 -0700, James Pye wrote: I think of a PL/Python function as a Python script file stored in the database. For Python, I think that's a mistake. Python scripts are independent applications. Is there any precedent for the sort of behavior that you are

Re: [HACKERS] Python 3.1 support

On sön, 2009-11-15 at 18:39 -0700, James Pye wrote: I can see how function modules might look like a half-step backwards from function fragments at first, but the benefits of a *natural* initialization section (the module body) was enough to convince me. The added value on the PL

Re: [HACKERS] Python 3.1 support

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. Also, I am a little skeptical about this patch. I am sorry if this has already been

Re: [HACKERS] Python 3.1 support

Nathan Boley npbo...@gmail.com writes: 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.*? Yes. That's exactly what I was complaining about

Re: [HACKERS] Python 3.1 support

On Wed, 2009-11-18 at 12:06 -0500, Tom Lane wrote: Nathan Boley npbo...@gmail.com writes: 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.*?

Re: [HACKERS] Python 3.1 support

Joshua D. Drake j...@commandprompt.com writes: On Wed, 2009-11-18 at 12:06 -0500, Tom Lane wrote: Yes. That's exactly what I was complaining about upthread. I'm not a Python user, but from what I can gather of the 2-to-3 changes, having to choose one at package build time is going to be a

Re: [HACKERS] Python 3.1 support

On Wed, 2009-11-18 at 12:28 -0500, Tom Lane wrote: Joshua D. Drake j...@commandprompt.com writes: On Wed, 2009-11-18 at 12:06 -0500, Tom Lane wrote: Yes. That's exactly what I was complaining about upthread. I'm not a Python user, but from what I can gather of the 2-to-3 changes, having

Re: [HACKERS] Python 3.1 support

Joshua D. Drake j...@commandprompt.com writes: On Wed, 2009-11-18 at 12:28 -0500, Tom Lane wrote: Peter was concerned about duplicative maintenance effort, but what I think this patch shows is that (at least for the near future) both could be built from a single source file. That seems

Re: [HACKERS] Python 3.1 support

Here's the patch to support Python =3.1 with PL/Python.  The compatibility code is mostly in line with the usual 2-3 C porting practice and is documented inline. I took a cursory look at this patch and, while the logic seems sound and roughly in line with the suggested python porting

Re: [HACKERS] Python 3.1 support

On Nov 18, 2009, at 8:37 AM, Peter Eisentraut wrote: The question is whether it helps the user, not the implementer. Sure, but do you have a patch waiting to implement tracebacks? I'd argue the reason it's never been done is due to the way procedures are currently managed in PL/Python. And

Re: [HACKERS] Python 3.1 support

On Nov 18, 2009, at 1:36 PM, James Pye wrote: At this point, I'm not going to try getting it into PG. (apparent futility and such) ugh, on second thought, I think I've written a bit too much code to stop now. I'm going to get plpython3 as far as I can and submit it to the next commitfest. --

Re: [HACKERS] Python 3.1 support

On fre, 2009-11-13 at 11:27 -0700, James Pye wrote: Some are TODOs, so in part by other people. Some were briefly touched on in the recent past discussions(around the time that I announced the WIP). Native typing vs conversion, function fragments vs function modules. I'm of course only one

Re: [HACKERS] Python 3.1 support

On Nov 15, 2009, at 6:37 AM, Peter Eisentraut wrote: but these two features don't excite me at all, hrm.. at all? I can see how function modules might look like a half-step backwards from function fragments at first, but the benefits of a *natural* initialization section (the module body)

Re: [HACKERS] Python 3.1 support

On tor, 2009-11-12 at 16:06 -0500, Tom Lane wrote: Peter Eisentraut pete...@gmx.net writes: Here's the patch to support Python =3.1 with PL/Python. The compatibility code is mostly in line with the usual 2-3 C porting practice and is documented inline. There was considerable debate

Re: [HACKERS] Python 3.1 support

On tor, 2009-11-12 at 18:42 -0700, James Pye wrote: For me, plpython has never been what I would call a pleasure to use, and many of the gripes that I have with it are, IMO, entrenched far enough into the implementation that any efforts to change it would(should? =) cause unacceptable breakage

Re: [HACKERS] Python 3.1 support

On Nov 13, 2009, at 4:47 AM, Peter Eisentraut wrote: Has this list of gripes ever been brought up and discussed in this forum? Some are TODOs, so in part by other people. Some were briefly touched on in the recent past discussions(around the time that I announced the WIP). Native typing vs

[HACKERS] Python 3.1 support

Here's the patch to support Python =3.1 with PL/Python. The compatibility code is mostly in line with the usual 2-3 C porting practice and is documented inline. I needed to create an arguably weird hack to manage the regression tests. Instead of creating a new expected file for pretty much

Re: [HACKERS] Python 3.1 support

Peter Eisentraut pete...@gmx.net writes: Here's the patch to support Python =3.1 with PL/Python. The compatibility code is mostly in line with the usual 2-3 C porting practice and is documented inline. There was considerable debate earlier about whether we wanted to treat Python 3 as a

Re: [HACKERS] Python 3.1 support

On Nov 12, 2009, at 12:54 PM, Peter Eisentraut wrote: Here's the patch to support Python =3.1 with PL/Python. :\ I was hoping to be able to use Python 3 to draw a clear distinction between plpython and the would-be plpython3 that I've been working on. I understand that you're not in favor of

Re: [HACKERS] Python 3.0 does not work with PL/Python

On Friday 29 May 2009 03:53:17 Alvaro Herrera wrote: Bruce Momjian escribió: Peter Eisentraut wrote: On Monday 06 April 2009 02:10:59 James Pye wrote: Any thoughts on the acceptability of a complete rewrite for Python 3? http://www.joelonsoftware.com/articles/fog69.html

Re: [HACKERS] Python 3.0 does not work with PL/Python

On Friday 29 May 2009 04:06:14 Andrew Dunstan wrote: Otherwise, I'm not too keen simply to throw Python 2.x overboard until it's no longer common on platforms people are likely to want to install Postgres on, if that's what's implied by the original question. My guess is that we will need to

Re: [HACKERS] Python 3.0 does not work with PL/Python

On Thu, May 28, 2009 at 09:06:14PM -0400, Andrew Dunstan wrote: Does Python 3 have some sort of usable sandbox that would mean we could have a trusted plpython? Not sure if people are aware of object-capability based approaches to security. A guy called Tav has come up with some code that

Re: [HACKERS] Python 3.0 does not work with PL/Python

On Thu, May 28, 2009 at 9:06 PM, Andrew Dunstan and...@dunslane.net wrote: Does Python 3 have some sort of usable sandbox that would mean we could have a trusted plpython? I brought this up last August [1]. Zope has a working sandbox that they include in their distribution. David Blewett 1.

Re: [HACKERS] Python 3.0 does not work with PL/Python

David Blewett wrote: On Thu, May 28, 2009 at 9:06 PM, Andrew Dunstan and...@dunslane.net mailto:and...@dunslane.net wrote: Does Python 3 have some sort of usable sandbox that would mean we could have a trusted plpython? I brought this up last August [1]. Zope has a working sandbox

Re: [HACKERS] Python 3.0 does not work with PL/Python

Andrew Dunstan and...@dunslane.net writes: David Blewett wrote: I brought this up last August [1]. Zope has a working sandbox that they include in their distribution. http://archives.postgresql.org/message-id/9d1f8d830808041008v50104fd8p6181d5ddce85...@mail.gmail.com How many python

Re: [HACKERS] Python 3.0 does not work with PL/Python

On Fri, 2009-05-29 at 11:12 +0300, Peter Eisentraut wrote: On Friday 29 May 2009 03:53:17 Alvaro Herrera wrote: Bruce Momjian escribió: Peter Eisentraut wrote: On Monday 06 April 2009 02:10:59 James Pye wrote: Any thoughts on the acceptability of a complete rewrite for Python 3?

Re: [HACKERS] Python 3.0 does not work with PL/Python

On May 29, 2009, at 1:17 AM, Peter Eisentraut wrote: On Friday 29 May 2009 04:06:14 Andrew Dunstan wrote: Otherwise, I'm not too keen simply to throw Python 2.x overboard until it's no longer common on platforms people are likely to want to install Postgres on, if that's what's implied by

Re: [HACKERS] Python 3.0 does not work with PL/Python

Peter Eisentraut wrote: On Monday 06 April 2009 02:10:59 James Pye wrote: Any thoughts on the acceptability of a complete rewrite for Python 3? http://www.joelonsoftware.com/articles/fog69.html You usually have to rewrite when you have not done refactoring as part of development;

Re: [HACKERS] Python 3.0 does not work with PL/Python

Bruce Momjian escribió: Peter Eisentraut wrote: On Monday 06 April 2009 02:10:59 James Pye wrote: Any thoughts on the acceptability of a complete rewrite for Python 3? http://www.joelonsoftware.com/articles/fog69.html You usually have to rewrite when you have not done

Re: [HACKERS] Python 3.0 does not work with PL/Python

Alvaro Herrera wrote: Bruce Momjian escribió: Peter Eisentraut wrote: On Monday 06 April 2009 02:10:59 James Pye wrote: Any thoughts on the acceptability of a complete rewrite for Python 3? http://www.joelonsoftware.com/articles/fog69.html You

Re: [HACKERS] Python 3.0 does not work with PL/Python

No. Still no sandbox. -Caleb On 5/28/09 6:06 PM, Andrew Dunstan and...@dunslane.net wrote: Does Python 3 have some sort of usable sandbox that would mean we could have a trusted plpython? Otherwise, I'm not too keen simply to throw Python 2.x overboard until it's no longer common on platforms

Re: [HACKERS] Python 3.0 does not work with PL/Python

On Monday 06 April 2009 02:10:59 James Pye wrote: Any thoughts on the acceptability of a complete rewrite for Python 3? http://www.joelonsoftware.com/articles/fog69.html -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription:

Re: [HACKERS] Python 3.0 does not work with PL/Python

On May 3, 2009, at 11:02 PM, Peter Eisentraut wrote: http://www.joelonsoftware.com/articles/fog69.html Good read. =) However, complete rewrite being relative in this case: WIP:

Re: [HACKERS] Python 3.0 does not work with PL/Python

On Thu, Apr 30, 2009 at 8:30 AM, James Pye li...@jwp.name wrote: On Apr 30, 2009, at 5:09 AM, David Blewett wrote: I'd love to see this. yep, once I get 0.9 of the driver out the door, I'll probably focus on this. It's the perfect time for a rewrite.. I really don't want to see the 2.x

Re: [HACKERS] Python 3.0 does not work with PL/Python

On Sun, Apr 5, 2009 at 7:10 PM, James Pye li...@jwp.name wrote: Any thoughts on the acceptability of a complete rewrite for Python 3? I've been fiddling with a HEAD branch including the plpy code in a github repo. (nah it dunt compile yet: bitrot and been busy with a 3.x driver. ;) I'd love to

Re: [HACKERS] Python 3.0 does not work with PL/Python

On 4/4/09, Tom Lane t...@sss.pgh.pa.us wrote: Peter Eisentraut pete...@gmx.net writes: I have recently fixed the configure script to recognize Python 3.0. But note that building and running PL/Python with Python 3.0 does not actually work. It looks like several symbols have been

Re: [HACKERS] Python 3.0 does not work with PL/Python

Marko Kreen mark...@gmail.com writes: On 4/4/09, Tom Lane t...@sss.pgh.pa.us wrote: So my conclusion is that Python 3.0 is much too wet behind the ears for us to worry about in PG 8.4. I'd guess that we should come back to the issue towards the end of 2009, and perhaps think about

Re: [HACKERS] Python 3.0 does not work with PL/Python

On Apr 5, 2009, at 8:54 AM, Tom Lane wrote: Hm, did you read the link I cited? It's not so surprising that 3.0 should have broken distutils, but what I found distressing is that they fixed distutils and then 3.0.1 broke it *again*. I stand by my opinion that Python 3 isn't stable yet.

Re: [HACKERS] Python 3.0 does not work with PL/Python

James Pye li...@jwp.name writes: Any thoughts on the acceptability of a complete rewrite for Python 3? I've always thought that plpython.c was a bit on the hackish side. If we do decide we have to make plpython2 and plpython3 separate languages, it'd be pretty easy to just start over with a

Re: [HACKERS] Python 3.0 does not work with PL/Python

Tom Lane wrote: I thought I would experiment with this a bit. I got past Python's configure; make; make install okay, but got no further than here with building PG: Consequently, I have removed the Python 3.0 item from the open items list and added a link to this thread to the TODO item that

Re: [HACKERS] Python 3.0 does not work with PL/Python

Peter Eisentraut pete...@gmx.net writes: I have recently fixed the configure script to recognize Python 3.0. But note that building and running PL/Python with Python 3.0 does not actually work. It looks like several symbols have been removed or changed. It would be good if the Python

Re: [HACKERS] Python 3.0 does not work with PL/Python

Bruce Momjian wrote: Peter Eisentraut wrote: I have recently fixed the configure script to recognize Python 3.0. But note that building and running PL/Python with Python 3.0 does not actually work. It looks like several symbols have been removed or changed. It would be good if the Python

Re: [HACKERS] Python 3.0 does not work with PL/Python

Peter Eisentraut wrote: I have recently fixed the configure script to recognize Python 3.0. But note that building and running PL/Python with Python 3.0 does not actually work. It looks like several symbols have been removed or changed. It would be good if the Python pundits around here

[HACKERS] Python 3.0 does not work with PL/Python

I have recently fixed the configure script to recognize Python 3.0. But note that building and running PL/Python with Python 3.0 does not actually work. It looks like several symbols have been removed or changed. It would be good if the Python pundits around here could take a look. (I

Re: [HACKERS] Python 3.0 does not work with PL/Python

On Thu, 2009-01-08 at 11:38 +0200, Peter Eisentraut wrote: I have recently fixed the configure script to recognize Python 3.0. But note that building and running PL/Python with Python 3.0 does not actually work. It looks like several symbols have been removed or changed. It would be good

  1   2   >