Noah Misch writes:
> On Wed, Feb 19, 2020 at 08:42:36PM +0100, Peter Eisentraut wrote:
>> I think there should just
>> be an option "plpython is: {2|3|don't build it at all}". Then packagers can
>> match this to what their plan for /usr/bin/python* is -- which appears to be
>> different
On Wed, Feb 19, 2020 at 08:42:36PM +0100, Peter Eisentraut wrote:
> I think there should just
> be an option "plpython is: {2|3|don't build it at all}". Then packagers can
> match this to what their plan for /usr/bin/python* is -- which appears to be
> different everywhere.
Today, we do not give
I wrote:
> [ a couple patches ]
Ping? I wish somebody would review this. I'm not wedded to any
of the details, but it would be an embarrassment for us to ship v13
without any response to the fact that Python 2 is EOL.
regards, tom lane
Marco Atzeri writes:
> Am 17.02.2020 um 17:49 schrieb Tom Lane:
>> 1. On platforms where Python 2.x is still supported, recommend that
>> packagers continue to build both plpython2 and plpython3, same as now.
> there is some documentation on how to build both ?
> The INSTALL gives no hint.
It's
On 2020-03-26 06:46, Marco Atzeri wrote:
Am 17.02.2020 um 17:49 schrieb Tom Lane:
We've had multiple previous discussions of $SUBJECT (eg [1][2]),
without any resolution of what to do exactly. Thinking about this
some more, I had an idea that I don't think has been discussed.
To wit:
1. On
Am 17.02.2020 um 17:49 schrieb Tom Lane:
We've had multiple previous discussions of $SUBJECT (eg [1][2]),
without any resolution of what to do exactly. Thinking about this
some more, I had an idea that I don't think has been discussed.
To wit:
1. On platforms where Python 2.x is still
Andrew Dunstan writes:
> On Thu, Feb 27, 2020 at 1:33 AM Tom Lane wrote:
>> OK, so we need that *and* the AddProject addition you mentioned?
> Yes, the first one builds it, the second one fixes the tests to run correctly.
Thanks, here's a patchset incorporating those fixes. Otherwise
same as
On Thu, Feb 27, 2020 at 1:33 AM Tom Lane wrote:
>
> Andrew Dunstan writes:
> > This seems to fix it.
>
> OK, so we need that *and* the AddProject addition you mentioned?
>
>
Yes, the first one builds it, the second one fixes the tests to run correctly.
cheers
andrew
--
Andrew Dunstan
Andrew Dunstan writes:
> This seems to fix it.
OK, so we need that *and* the AddProject addition you mentioned?
regards, tom lane
On 2/26/20 3:17 AM, Andrew Dunstan wrote:
> On 2/26/20 2:47 AM, Andrew Dunstan wrote:
>> On 2/25/20 8:24 PM, Andrew Dunstan wrote:
>>> On 2/25/20 7:08 PM, Tom Lane wrote:
Andrew Dunstan writes:
> On 2/25/20 5:06 PM, Tom Lane wrote:
>> No joy there --- now that I look closer, it
On 2/26/20 2:47 AM, Andrew Dunstan wrote:
> On 2/25/20 8:24 PM, Andrew Dunstan wrote:
>> On 2/25/20 7:08 PM, Tom Lane wrote:
>>> Andrew Dunstan writes:
On 2/25/20 5:06 PM, Tom Lane wrote:
> No joy there --- now that I look closer, it seems the cfbot doesn't
> build any of the
On 2/25/20 8:24 PM, Andrew Dunstan wrote:
> On 2/25/20 7:08 PM, Tom Lane wrote:
>> Andrew Dunstan writes:
>>> On 2/25/20 5:06 PM, Tom Lane wrote:
No joy there --- now that I look closer, it seems the cfbot doesn't
build any of the external-language PLs on Windows. I'll have to
On 2/25/20 7:08 PM, Tom Lane wrote:
> Andrew Dunstan writes:
>> On 2/25/20 5:06 PM, Tom Lane wrote:
>>> No joy there --- now that I look closer, it seems the cfbot doesn't
>>> build any of the external-language PLs on Windows. I'll have to
>>> wait for some reviewer to try it.
>> What are the
Andrew Dunstan writes:
> On 2/25/20 5:06 PM, Tom Lane wrote:
>> No joy there --- now that I look closer, it seems the cfbot doesn't
>> build any of the external-language PLs on Windows. I'll have to
>> wait for some reviewer to try it.
> What are the requirements for testing? bowerbird builds
On 2/25/20 5:06 PM, Tom Lane wrote:
> I wrote:
>> I set up the MSVC scripts to default to building the stub extension.
>> I don't know if we really want to commit it that way, but the idea
>> for the moment is to try to get the cfbot to test it on Windows.
> No joy there --- now that I look
I wrote:
> I set up the MSVC scripts to default to building the stub extension.
> I don't know if we really want to commit it that way, but the idea
> for the moment is to try to get the cfbot to test it on Windows.
No joy there --- now that I look closer, it seems the cfbot doesn't
build any of
I wrote:
> Here's an updated pair of patches that attempt to fix the MSVC
> scripts (pretty blindly) and provide a very simple regression test.
A little *too* blindly, evidently. Try again ...
regards, tom lane
diff --git a/doc/src/sgml/plpython.sgml
Here's an updated pair of patches that attempt to fix the MSVC
scripts (pretty blindly) and provide a very simple regression test.
I'm not too sure whether the regression test will really prove
workable or not: for starters, it'll fail if "2to3" isn't available
in the PATH. Perhaps there's reason
Peter Eisentraut writes:
> Your scheme appears to center around the assumption that people will
> want to port their functions at the same time as not building plpython2u
> anymore.
Not really; use of the proposed porting infrastructure is the same whether
plpython2u still works or not. You
On 2020-02-19 05:39, Tom Lane wrote:
After thinking about this awhile longer, I'm starting to believe
we should do some of each. That is, the stub replacement for
plpython2.so should redirect "plpythonu" functions to plpython3.so,
but throw errors for "plpython2u" functions.
I'm not sure
After thinking about this awhile longer, I'm starting to believe
we should do some of each. That is, the stub replacement for
plpython2.so should redirect "plpythonu" functions to plpython3.so,
but throw errors for "plpython2u" functions. This is not because
of any technical difference between
>
> So, as with Jesse's example, what I'm wondering is whether or not 2to3
> will fix that for you (or even flag it). The basic difference between
> the two alternatives I suggested is whether we force people to put their
> python function through that converter before we'll even try to run it.
>
Corey Huinker writes:
>> A possible gotcha in this approach is if there are any python 2/3
>> incompatibilities that would not manifest as syntax errors or
>> obvious runtime errors, but would allow old code to execute and
>> silently do the wrong thing.
> Unfortunately, I think there are cases
>
> A possible gotcha in this approach is if there are any python 2/3
> incompatibilities that would not manifest as syntax errors or
> obvious runtime errors, but would allow old code to execute and
> silently do the wrong thing. One would hope that the Python crowd
> weren't dumb enough to do
Jesse Zhang writes:
> I really like the "stub .so" idea, but feel pretty uncomfortable for the
> "transparent" upgrade. Response inlined.
Fair enough, but ...
>> 2. On platforms where Python 2.x is no longer supported, transparently
>> map plpythonu and plpython2u to plpython3u. "Transparent"
Hi Tom,
I really like the "stub .so" idea, but feel pretty uncomfortable for the
"transparent" upgrade. Response inlined.
On Mon, Feb 17, 2020 at 8:49 AM Tom Lane wrote:
>
> 2. On platforms where Python 2.x is no longer supported, transparently
> map plpythonu and plpython2u to plpython3u.
We've had multiple previous discussions of $SUBJECT (eg [1][2]),
without any resolution of what to do exactly. Thinking about this
some more, I had an idea that I don't think has been discussed.
To wit:
1. On platforms where Python 2.x is still supported, recommend that
packagers continue to
27 matches
Mail list logo
