pgsql: Add transforms feature

Peter Eisentraut <peter_e@gmx.net> writes:

Add transforms feature

I don't know why this patch is fooling around with compile/link flags,
but it's broken at least prairiedog and some of the Windows critters.

regards, tom lane

--
Sent via pgsql-committers mailing list (pgsql-committers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-committers

On Mon, Apr 27, 2015 at 1:36 AM, Tom Lane <tgl@sss.pgh.pa.us> wrote:

Peter Eisentraut <peter_e@gmx.net> writes:

Add transforms feature

I don't know why this patch is fooling around with compile/link flags,
but it's broken at least prairiedog and some of the Windows critters.

It breaks as well on all the Windows machines using MS or VC toolchains...
--
Michael

--
Sent via pgsql-committers mailing list (pgsql-committers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-committers

On 4/27/15 2:23 AM, Michael Paquier wrote:

On Mon, Apr 27, 2015 at 1:36 AM, Tom Lane <tgl@sss.pgh.pa.us> wrote:

Peter Eisentraut <peter_e@gmx.net> writes:

Add transforms feature

I don't know why this patch is fooling around with compile/link flags,
but it's broken at least prairiedog and some of the Windows critters.

It breaks as well on all the Windows machines using MS or VC toolchains...

The failure on bowerbird (Windows msvc) is because the build system
needs to be told to add additional include directories to the compilation.

The failure on frogmouth (Windows gcc) is because of some conflict with
perl headers. I must have missed a trick that was already in use for
plperl.

Help in either case, but especially the first one, is welcome.

--
Sent via pgsql-committers mailing list (pgsql-committers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-committers

Peter Eisentraut wrote:

Add transforms feature

This provides a mechanism for specifying conversions between SQL data
types and procedural languages. As examples, there are transforms
for hstore and ltree for PL/Perl and PL/Python.

BF member olinguito is also failing the contrib test, because plpython
is not compiled in that platform.

--
�lvaro Herrera http://www.2ndQuadrant.com/
PostgreSQL Development, 24x7 Support, Remote DBA, Training & Services

--
Sent via pgsql-committers mailing list (pgsql-committers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-committers

On 04/27/2015 08:21 AM, Peter Eisentraut wrote:

On 4/27/15 2:23 AM, Michael Paquier wrote:

On Mon, Apr 27, 2015 at 1:36 AM, Tom Lane <tgl@sss.pgh.pa.us> wrote:

Peter Eisentraut <peter_e@gmx.net> writes:

Add transforms feature

I don't know why this patch is fooling around with compile/link flags,
but it's broken at least prairiedog and some of the Windows critters.

It breaks as well on all the Windows machines using MS or VC toolchains...

The failure on bowerbird (Windows msvc) is because the build system
needs to be told to add additional include directories to the compilation.

The failure on frogmouth (Windows gcc) is because of some conflict with
perl headers. I must have missed a trick that was already in use for
plperl.

Help in either case, but especially the first one, is welcome.

I haven't looked at the MSVC case yet, but one thing I notice on jacana
(Windows 8.1, gcc) is that the order of include directories is
different. When compiling plperl, the perl CORE directory is last in the
include list, whereas for compiling hstore_plperl it's second from the
beginning. I have no idea yet if that makes any difference, but would
not be at all surprised it if did. We should probably be mimicking what
the plperl makefile does.

Incidentally, I notice that hstore_plperl.c doesn't have a copyright
notice nor a single comment, not even at the start of the public
functions. That seems less than good.

cheers

andrew

--
Sent via pgsql-committers mailing list (pgsql-committers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-committers

On 04/27/2015 07:54 PM, Andrew Dunstan wrote:

On 04/27/2015 08:21 AM, Peter Eisentraut wrote:

On 4/27/15 2:23 AM, Michael Paquier wrote:

On Mon, Apr 27, 2015 at 1:36 AM, Tom Lane <tgl@sss.pgh.pa.us> wrote:

Peter Eisentraut <peter_e@gmx.net> writes:

Add transforms feature

I don't know why this patch is fooling around with compile/link flags,
but it's broken at least prairiedog and some of the Windows critters.

It breaks as well on all the Windows machines using MS or VC
toolchains...

The failure on bowerbird (Windows msvc) is because the build system
needs to be told to add additional include directories to the
compilation.

The failure on frogmouth (Windows gcc) is because of some conflict with
perl headers. I must have missed a trick that was already in use for
plperl.

Help in either case, but especially the first one, is welcome.

I haven't looked at the MSVC case yet, but one thing I notice on
jacana (Windows 8.1, gcc) is that the order of include directories is
different. When compiling plperl, the perl CORE directory is last in
the include list, whereas for compiling hstore_plperl it's second from
the beginning. I have no idea yet if that makes any difference, but
would not be at all surprised it if did. We should probably be
mimicking what the plperl makefile does.

Incidentally, I notice that hstore_plperl.c doesn't have a copyright
notice nor a single comment, not even at the start of the public
functions. That seems less than good.

w.r.t MSVC builds, it looks like we need entries in
$contrib_extraincludes in src/tools/msvc/Mkvcbuild.pm at the very least.

cheers

andrew

--
Sent via pgsql-committers mailing list (pgsql-committers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-committers

On Tue, Apr 28, 2015 at 9:55 AM, Andrew Dunstan wrote:

w.r.t MSVC builds, it looks like we need entries in $contrib_extraincludes
in src/tools/msvc/Mkvcbuild.pm at the very least.

If our goal is to put back to green the Windows nodes as quick as
possible, we could bypass their build this way , and we'll
additionally need to update the install script and
vcregress.pl/contribcheck to bypass those modules accordingly. Now I
don't think that we should make the things produced inconsistent.
--
Michael

--
Sent via pgsql-committers mailing list (pgsql-committers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-committers

Alvaro Herrera <alvherre@2ndquadrant.com> writes:

Peter Eisentraut wrote:

Add transforms feature

BF member olinguito is also failing the contrib test, because plpython
is not compiled in that platform.

Yeah. Even more specifically, olinguito does have --with-python in its
configure flags, but then the plpython Makefile skips the build because
libpython isn't available as a shared library. But the contrib test is
(I assume, haven't looked) conditional only on the configure flag.

I'm not real sure now why we felt that was a good approach. The general
project policy is that if you ask for a feature in the configure flags,
we'll build it or die trying; how come this specific Python issue gets
special treatment contrary to that policy?

So I'd vote for changing that to put the shared-library test in configure,
or at least make it a build failure later on, not "silently don't build
what was asked for". That would mean olinguito's configure flags would
have to be adjusted.

Plan B would require propagating the shared-libpython test into the
contrib makefiles, which seems pretty unpalatable even if you're willing
to defend the status quo otherwise.

regards, tom lane

--
Sent via pgsql-committers mailing list (pgsql-committers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-committers

On Tue, Apr 28, 2015 at 10:01 AM, Michael Paquier
<michael.paquier@gmail.com> wrote:

On Tue, Apr 28, 2015 at 9:55 AM, Andrew Dunstan wrote:

w.r.t MSVC builds, it looks like we need entries in $contrib_extraincludes
in src/tools/msvc/Mkvcbuild.pm at the very least.

If our goal is to put back to green the Windows nodes as quick as
possible, we could bypass their build this way , and we'll
additionally need to update the install script and
vcregress.pl/contribcheck to bypass those modules accordingly. Now I
don't think that we should make the things produced inconsistent.

OK, attached are two patches to put back the buildfarm nodes using MSVC to green
- 0001 adds support for build and installation of the new transform
modules: hstore_plperl, hstore_plpython and ltree_plpython. Note that
this patch is enough to put back the buildfarm to a green state for
MSVC, but it disables the regression tests for those modules,
something addressed in the next patch...
- 0002 adds support for regression tests for the new modules. The
thing is that we need to check the major version version of Python
available in configuration and choose what are the extensions to
preload before the tests run. It is a little bit hacky... But it has
the merit to work, and I am not sure we could have a cleaner solution
by looking at the Makefiles of the transform modules that use
currently conditions based on $(python_majorversion).
Regards,
--
Michael

On 04/28/2015 09:04 AM, Michael Paquier wrote:

On Tue, Apr 28, 2015 at 10:01 AM, Michael Paquier
<michael.paquier@gmail.com> wrote:

On Tue, Apr 28, 2015 at 9:55 AM, Andrew Dunstan wrote:

w.r.t MSVC builds, it looks like we need entries in $contrib_extraincludes
in src/tools/msvc/Mkvcbuild.pm at the very least.

If our goal is to put back to green the Windows nodes as quick as
possible, we could bypass their build this way , and we'll
additionally need to update the install script and
vcregress.pl/contribcheck to bypass those modules accordingly. Now I
don't think that we should make the things produced inconsistent.

OK, attached are two patches to put back the buildfarm nodes using MSVC to green
- 0001 adds support for build and installation of the new transform
modules: hstore_plperl, hstore_plpython and ltree_plpython. Note that
this patch is enough to put back the buildfarm to a green state for
MSVC, but it disables the regression tests for those modules,
something addressed in the next patch...
- 0002 adds support for regression tests for the new modules. The
thing is that we need to check the major version version of Python
available in configuration and choose what are the extensions to
preload before the tests run. It is a little bit hacky... But it has
the merit to work, and I am not sure we could have a cleaner solution
by looking at the Makefiles of the transform modules that use
currently conditions based on $(python_majorversion).
Regards,

I have pushed the first of these with some tweaks.

I'm looking at the second.

cheers

andrew

--
Sent via pgsql-committers mailing list (pgsql-committers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-committers

[switching to -hackers]

On 04/28/2015 11:51 AM, Andrew Dunstan wrote:

On 04/28/2015 09:04 AM, Michael Paquier wrote:

On Tue, Apr 28, 2015 at 10:01 AM, Michael Paquier
<michael.paquier@gmail.com> wrote:

On Tue, Apr 28, 2015 at 9:55 AM, Andrew Dunstan wrote:

w.r.t MSVC builds, it looks like we need entries in
$contrib_extraincludes
in src/tools/msvc/Mkvcbuild.pm at the very least.

If our goal is to put back to green the Windows nodes as quick as
possible, we could bypass their build this way , and we'll
additionally need to update the install script and
vcregress.pl/contribcheck to bypass those modules accordingly. Now I
don't think that we should make the things produced inconsistent.

OK, attached are two patches to put back the buildfarm nodes using
MSVC to green
- 0001 adds support for build and installation of the new transform
modules: hstore_plperl, hstore_plpython and ltree_plpython. Note that
this patch is enough to put back the buildfarm to a green state for
MSVC, but it disables the regression tests for those modules,
something addressed in the next patch...
- 0002 adds support for regression tests for the new modules. The
thing is that we need to check the major version version of Python
available in configuration and choose what are the extensions to
preload before the tests run. It is a little bit hacky... But it has
the merit to work, and I am not sure we could have a cleaner solution
by looking at the Makefiles of the transform modules that use
currently conditions based on $(python_majorversion).
Regards,

I have pushed the first of these with some tweaks.

I'm looking at the second.

Regarding this second patch - apart from the buggy python version test
which I just fixed in the first patch, I see this:

    +       if ($pyver eq "2")
    +       {
    +           push @opts, "--load-extension=plpythonu";
    +           push @opts, '--load-extension=' . $module . 'u';
    +       }

But what do we do for Python3?

Do we actually have a Windows machine building with Python3?

cheers

andrew

--
Sent via pgsql-committers mailing list (pgsql-committers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-committers

Oops, thought I'd changed the address line.

[switching to -hackers]

On 04/28/2015 11:51 AM, Andrew Dunstan wrote:

On 04/28/2015 09:04 AM, Michael Paquier wrote:

On Tue, Apr 28, 2015 at 10:01 AM, Michael Paquier
<michael.paquier@gmail.com> wrote:

On Tue, Apr 28, 2015 at 9:55 AM, Andrew Dunstan wrote:

w.r.t MSVC builds, it looks like we need entries in
$contrib_extraincludes
in src/tools/msvc/Mkvcbuild.pm at the very least.

If our goal is to put back to green the Windows nodes as quick as
possible, we could bypass their build this way , and we'll
additionally need to update the install script and
vcregress.pl/contribcheck to bypass those modules accordingly. Now I
don't think that we should make the things produced inconsistent.

OK, attached are two patches to put back the buildfarm nodes using
MSVC to green
- 0001 adds support for build and installation of the new transform
modules: hstore_plperl, hstore_plpython and ltree_plpython. Note that
this patch is enough to put back the buildfarm to a green state for
MSVC, but it disables the regression tests for those modules,
something addressed in the next patch...
- 0002 adds support for regression tests for the new modules. The
thing is that we need to check the major version version of Python
available in configuration and choose what are the extensions to
preload before the tests run. It is a little bit hacky... But it has
the merit to work, and I am not sure we could have a cleaner solution
by looking at the Makefiles of the transform modules that use
currently conditions based on $(python_majorversion).
Regards,

I have pushed the first of these with some tweaks.

I'm looking at the second.

Regarding this second patch - apart from the buggy python version test
which I just fixed in the first patch, I see this:

    +       if ($pyver eq "2")
    +       {
    +           push @opts, "--load-extension=plpythonu";
    +           push @opts, '--load-extension=' . $module . 'u';
    +       }

But what do we do for Python3?

Do we actually have a Windows machine building with Python3?

cheers

andrew

--
Sent via pgsql-committers mailing list (pgsql-committers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-committers

--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers

On 04/28/2015 12:03 PM, Andrew Dunstan wrote:

[switching to -hackers]

On 04/28/2015 11:51 AM, Andrew Dunstan wrote:

On 04/28/2015 09:04 AM, Michael Paquier wrote:

On Tue, Apr 28, 2015 at 10:01 AM, Michael Paquier
<michael.paquier@gmail.com> wrote:

On Tue, Apr 28, 2015 at 9:55 AM, Andrew Dunstan wrote:

w.r.t MSVC builds, it looks like we need entries in
$contrib_extraincludes
in src/tools/msvc/Mkvcbuild.pm at the very least.

If our goal is to put back to green the Windows nodes as quick as
possible, we could bypass their build this way , and we'll
additionally need to update the install script and
vcregress.pl/contribcheck to bypass those modules accordingly. Now I
don't think that we should make the things produced inconsistent.

OK, attached are two patches to put back the buildfarm nodes using
MSVC to green
- 0001 adds support for build and installation of the new transform
modules: hstore_plperl, hstore_plpython and ltree_plpython. Note that
this patch is enough to put back the buildfarm to a green state for
MSVC, but it disables the regression tests for those modules,
something addressed in the next patch...
- 0002 adds support for regression tests for the new modules. The
thing is that we need to check the major version version of Python
available in configuration and choose what are the extensions to
preload before the tests run. It is a little bit hacky... But it has
the merit to work, and I am not sure we could have a cleaner solution
by looking at the Makefiles of the transform modules that use
currently conditions based on $(python_majorversion).
Regards,

I have pushed the first of these with some tweaks.

I'm looking at the second.

Regarding this second patch - apart from the buggy python version test
which I just fixed in the first patch, I see this:

+       if ($pyver eq "2")
+       {
+           push @opts, "--load-extension=plpythonu";
+           push @opts, '--load-extension=' . $module . 'u';
+       }

But what do we do for Python3?

Do we actually have a Windows machine building with Python3?

The answer seems to be "probably not". When I tried enabling this with
bowerbird I got a ton of errors like these:

plpy_cursorobject.obj : error LNK2001: unresolved external symbol
PyObject_SelfIter [C:\prog\bf\root\HEAD\pgsql\plpython3.vcxproj]
plpy_cursorobject.obj : error LNK2019: unresolved external symbol
__imp_PyType_Ready referenced in function PLy_cursor_init_type
[C:\prog\bf\root\HEAD\pgsql\plpython3.vcxproj]

Something else to fix I guess.

cheers

andrew

--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers

On 4/28/15 4:10 PM, Andrew Dunstan wrote:

Do we actually have a Windows machine building with Python3?

The answer seems to be "probably not". When I tried enabling this with
bowerbird I got a ton of errors like these:

plpy_cursorobject.obj : error LNK2001: unresolved external symbol
PyObject_SelfIter [C:\prog\bf\root\HEAD\pgsql\plpython3.vcxproj]
plpy_cursorobject.obj : error LNK2019: unresolved external symbol
__imp_PyType_Ready referenced in function PLy_cursor_init_type
[C:\prog\bf\root\HEAD\pgsql\plpython3.vcxproj]

Something else to fix I guess.

I think at least at one point the community Windows binaries built by
EnterpriseDB were built against Python 3 (which upset some users). But
they might not be using the msvc toolchain.

--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers

On 4/28/15 12:05 AM, Tom Lane wrote:

Yeah. Even more specifically, olinguito does have --with-python in its
configure flags, but then the plpython Makefile skips the build because
libpython isn't available as a shared library. But the contrib test is
(I assume, haven't looked) conditional only on the configure flag.

I'm not real sure now why we felt that was a good approach. The general
project policy is that if you ask for a feature in the configure flags,
we'll build it or die trying; how come this specific Python issue gets
special treatment contrary to that policy?

So I'd vote for changing that to put the shared-library test in configure,
or at least make it a build failure later on, not "silently don't build
what was asked for". That would mean olinguito's configure flags would
have to be adjusted.

Plan B would require propagating the shared-libpython test into the
contrib makefiles, which seems pretty unpalatable even if you're willing
to defend the status quo otherwise.

I had tried plan B prime, moving the shared_libpython etc. detection
into Makefile.global. But that doesn't work because contrib/pgxs
makefiles require setting all variables *before* including the global
makefiles. So you can't decide whether you want to build something
before you have told it everything you want to build.

The reason for the current setup is actually that when plperl and later
plpython was added, we still had Perl and Python client modules in our
tree (Pg.pm and pygresql), and configure --with-perl and --with-python
were meant to activate their build primarily. Also, in those days,
having a shared libperl or libpython was rare. But we didn't want to
fail the frontend interface builds because of that. So we arrived at
the current workaround.

My preference would be to rip all that out and let the compiler or
linker decide when it doesn't want to link something.

The alternative would be creating a configure check that mirrors the
current logic. Arguably, however, the current logic is quite unworthy
of a configure check, because it's just a collection of
on-this-platform-do-that, instead of a real test. Then again, a real
test would require building and loading a shared library in configure,
and we are not set up for that.

Preferences?

--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers

On 04/28/2015 04:31 PM, Peter Eisentraut wrote:

On 4/28/15 12:05 AM, Tom Lane wrote:

Yeah. Even more specifically, olinguito does have --with-python in its
configure flags, but then the plpython Makefile skips the build because
libpython isn't available as a shared library. But the contrib test is
(I assume, haven't looked) conditional only on the configure flag.

I'm not real sure now why we felt that was a good approach. The general
project policy is that if you ask for a feature in the configure flags,
we'll build it or die trying; how come this specific Python issue gets
special treatment contrary to that policy?

So I'd vote for changing that to put the shared-library test in configure,
or at least make it a build failure later on, not "silently don't build
what was asked for". That would mean olinguito's configure flags would
have to be adjusted.

Plan B would require propagating the shared-libpython test into the
contrib makefiles, which seems pretty unpalatable even if you're willing
to defend the status quo otherwise.

I had tried plan B prime, moving the shared_libpython etc. detection
into Makefile.global. But that doesn't work because contrib/pgxs
makefiles require setting all variables *before* including the global
makefiles. So you can't decide whether you want to build something
before you have told it everything you want to build.

The reason for the current setup is actually that when plperl and later
plpython was added, we still had Perl and Python client modules in our
tree (Pg.pm and pygresql), and configure --with-perl and --with-python
were meant to activate their build primarily. Also, in those days,
having a shared libperl or libpython was rare. But we didn't want to
fail the frontend interface builds because of that. So we arrived at
the current workaround.

My preference would be to rip all that out and let the compiler or
linker decide when it doesn't want to link something.

The alternative would be creating a configure check that mirrors the
current logic. Arguably, however, the current logic is quite unworthy
of a configure check, because it's just a collection of
on-this-platform-do-that, instead of a real test. Then again, a real
test would require building and loading a shared library in configure,
and we are not set up for that.

Preferences?

In general I prefer things not being available to be tested at configure
time. After all, we check for libxml2, for example. Certainly silent
failure is a bad thing.

cheers

andrew

--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers

Peter Eisentraut <peter_e@gmx.net> writes:

On 4/28/15 12:05 AM, Tom Lane wrote:

Yeah. Even more specifically, olinguito does have --with-python in its
configure flags, but then the plpython Makefile skips the build because
libpython isn't available as a shared library. But the contrib test is
(I assume, haven't looked) conditional only on the configure flag.

I'm not real sure now why we felt that was a good approach. The general
project policy is that if you ask for a feature in the configure flags,
we'll build it or die trying; how come this specific Python issue gets
special treatment contrary to that policy?

The reason for the current setup is actually that when plperl and later
plpython was added, we still had Perl and Python client modules in our
tree (Pg.pm and pygresql), and configure --with-perl and --with-python
were meant to activate their build primarily. Also, in those days,
having a shared libperl or libpython was rare. But we didn't want to
fail the frontend interface builds because of that. So we arrived at
the current workaround.

Ah. I'm glad you remember, because I didn't.

My preference would be to rip all that out and let the compiler or
linker decide when it doesn't want to link something.

Works for me, assuming that we get an understandable failure message and
not, say, a plperl.so that mysteriously doesn't work.

regards, tom lane

--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers

On Wed, Apr 29, 2015 at 5:15 AM, Peter Eisentraut <peter_e@gmx.net> wrote:

On 4/28/15 4:10 PM, Andrew Dunstan wrote:

Do we actually have a Windows machine building with Python3?

The answer seems to be "probably not". When I tried enabling this with
bowerbird I got a ton of errors like these:

plpy_cursorobject.obj : error LNK2001: unresolved external symbol
PyObject_SelfIter [C:\prog\bf\root\HEAD\pgsql\plpython3.vcxproj]
plpy_cursorobject.obj : error LNK2019: unresolved external symbol
__imp_PyType_Ready referenced in function PLy_cursor_init_type
[C:\prog\bf\root\HEAD\pgsql\plpython3.vcxproj]

Something else to fix I guess.

I think at least at one point the community Windows binaries built by
EnterpriseDB were built against Python 3 (which upset some users). But
they might not be using the msvc toolchain.

Er, aren't you simply trying to link with 32b libraries while building
in a 64b environment? I am able to make the build work with python 3.
--
Michael

--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers

On Wed, Apr 29, 2015 at 12:48 PM, Tom Lane <tgl@sss.pgh.pa.us> wrote:

Peter Eisentraut <peter_e@gmx.net> writes:

On 4/28/15 12:05 AM, Tom Lane wrote:

Yeah. Even more specifically, olinguito does have --with-python in its
configure flags, but then the plpython Makefile skips the build because
libpython isn't available as a shared library. But the contrib test is
(I assume, haven't looked) conditional only on the configure flag.

I'm not real sure now why we felt that was a good approach. The general
project policy is that if you ask for a feature in the configure flags,
we'll build it or die trying; how come this specific Python issue gets
special treatment contrary to that policy?

The reason for the current setup is actually that when plperl and later
plpython was added, we still had Perl and Python client modules in our
tree (Pg.pm and pygresql), and configure --with-perl and --with-python
were meant to activate their build primarily. Also, in those days,
having a shared libperl or libpython was rare. But we didn't want to
fail the frontend interface builds because of that. So we arrived at
the current workaround.

Ah. I'm glad you remember, because I didn't.

Interesting, those are pieces of history:
commit: f10a9033bf308f9dde0aa77caad6503e233489d1
author: Peter Eisentraut <peter_e@gmx.net>
date: Mon, 1 Sep 2003 23:01:49 +0000
Clean up after pygresql removal: adjust/remove documentation and remove
unneeded configure work.

commit: 9a0b4d7f847469544798133391e221481548e1b9
author: Marc G. Fournier <scrappy@hub.org>
date: Fri, 30 Aug 2002 13:06:22 +0000

perl5 interface moved to gborg

My preference would be to rip all that out and let the compiler or
linker decide when it doesn't want to link something.

Works for me, assuming that we get an understandable failure message and
not, say, a plperl.so that mysteriously doesn't work.

+1.
-- 
Michael

--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers