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 deployments at this point, and

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 branch in the critter's >

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 w

[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 n

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. > > Well, that's

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 been back-patched

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 you

[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 looki

[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 tim

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 version dependency in plpython regression tests

Peter Eisentraut 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 >> not-val

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 wi

[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 t

Re: [HACKERS] python cleanup

On 07/25/2011 12:03 PM, Tom Lane wrote: Andrew Dunstan 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-head

Re: [HACKERS] python cleanup

Andrew Dunstan 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, for some reas

Re: [HACKERS] python cleanup

On 07/25/2011 10:52 AM, Tom Lane wrote: Andrew Dunstan writes: On 07/25/2011 10:36 AM, Tom Lane wrote: Andrew Dunstan 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 m

Re: [HACKERS] python cleanup

Andrew Dunstan writes: > On 07/25/2011 10:36 AM, Tom Lane wrote: >> Andrew Dunstan 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 >

Re: [HACKERS] python cleanup

On 07/25/2011 10:36 AM, Tom Lane wrote: Andrew Dunstan 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* head

Re: [HACKERS] python cleanup

Andrew Dunstan 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 setting them at all, rath

Re: [HACKERS] python cleanup

Andrew Dunstan 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 it > defi

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 a

Re: [HACKERS] python cleanup

Andrew Dunstan 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 _PGSAVE_POSIX_C_SOURCE _POSIX

[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 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: > > > http://lists.fedoraproject.org/pipermail/devel/

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

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 w

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

James William Pye 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 fo

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"); > P

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

James William Pye 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: > pro

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 t

[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? reg

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/

Re: [HACKERS] Python Interface Hacking

On 07/07/10 17:19, Peter Froehlich wrote: On Wed, Jul 7, 2010 at 8:49 AM, Peter Eisentraut 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 c

Re: [HACKERS] Python Interface Hacking

On Wed, Jul 7, 2010 at 8:49 AM, Peter Eisentraut 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 > http://in

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 3: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... Well

[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 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 thi

Re: [HACKERS] Python 3.1 support

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

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 thi

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-leve

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 igno

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 Postgre

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 pg

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? >

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 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 implem

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

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/Pyth

Re: [HACKERS] Python 3.1 support

Peter Eisentraut 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 globally visible.

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

Re: [HACKERS] Python 3.1 support

On ons, 2009-11-18 at 12:28 -0500, Tom Lane wrote: > "Joshua D. Drake" 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 choos

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

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 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, a

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 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 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 *wi

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 proc

Re: [HACKERS] Python 3.1 support

"Joshua D. Drake" 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 reasonable if we c

Re: [HACKERS] Python 3.1 support

On Wed, 2009-11-18 at 12:28 -0500, Tom Lane wrote: > "Joshua D. Drake" 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 choos

Re: [HACKERS] Python 3.1 support

"Joshua D. Drake" 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 disaster. > Agr

Re: [HACKERS] Python 3.1 support

On Wed, 2009-11-18 at 12:06 -0500, Tom Lane wrote: > Nathan Boley 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. Tha

Re: [HACKERS] Python 3.1 support

Nathan Boley 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 upthread. I'm not a P

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 be

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 develop

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) w

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 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

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 break

Re: [HACKERS] Python 3.1 support

On tor, 2009-11-12 at 16:06 -0500, Tom Lane wrote: > Peter Eisentraut 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 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

Re: [HACKERS] Python 3.1 support

Peter Eisentraut 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 separate PL so it

[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 eve

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 th

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

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

Andrew Dunstan 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 installations

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 > 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

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

On Thu, May 28, 2009 at 9:06 PM, Andrew Dunstan 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. http://archives.p

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 co

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 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/fog

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" 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 people are likely

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 usually

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 d

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

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: http://github.com/jwp/postgresql-plpython3/tree/c804e693b6a0df98c0e5c465e75ba2e9014ebf37/src/pl/plpython3

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: http://

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

On Sun, Apr 5, 2009 at 7:10 PM, James Pye 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 see this. I

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

On Thu, Apr 30, 2009 at 8:30 AM, James Pye 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 > version

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

James Pye 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 whole new implem

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. Ye

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

Marko Kreen writes: > On 4/4/09, Tom Lane 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 back-porting >> after we have something

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

On 4/4/09, Tom Lane wrote: > Peter Eisentraut 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 woul

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

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

Peter Eisentraut 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 pundits around

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 pu

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 he

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 g

[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 have

  1   2   >