pg.ddx.io pgsql-committers@postgresql.org mailing list archive
help / color / mirror / Atom feedpgsql: Add transforms feature
28+ messages / 5 participants
[nested] [flat]
* pgsql: Add transforms feature
@ 2015-04-26 14:53 Peter Eisentraut <peter_e@gmx.net>
2015-04-26 16:36 ` Re: pgsql: Add transforms feature Tom Lane <tgl@sss.pgh.pa.us>
2015-04-27 17:27 ` Re: pgsql: Add transforms feature Alvaro Herrera <alvherre@2ndquadrant.com>
0 siblings, 2 replies; 28+ messages in thread
From: Peter Eisentraut @ 2015-04-26 14:53 UTC (permalink / raw)
To: pgsql-committers
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.
reviews by Pavel Stěhule and Andres Freund
Branch
------
master
Details
-------
http://git.postgresql.org/pg/commitdiff/cac76582053ef8ea07df65fed0757f352da23705
Modified Files
--------------
contrib/Makefile | 12 +
contrib/hstore_plperl/.gitignore | 4 +
contrib/hstore_plperl/Makefile | 24 +
.../hstore_plperl/expected/create_transform.out | 74 +
contrib/hstore_plperl/expected/hstore_plperl.out | 213 +
contrib/hstore_plperl/hstore_plperl--1.0.sql | 17 +
contrib/hstore_plperl/hstore_plperl.c | 90 +
contrib/hstore_plperl/hstore_plperl.control | 6 +
contrib/hstore_plperl/hstore_plperlu--1.0.sql | 17 +
contrib/hstore_plperl/hstore_plperlu.control | 6 +
contrib/hstore_plperl/sql/create_transform.sql | 47 +
contrib/hstore_plperl/sql/hstore_plperl.sql | 148 +
contrib/hstore_plpython/.gitignore | 6 +
contrib/hstore_plpython/Makefile | 31 +
.../hstore_plpython/expected/hstore_plpython.out | 132 +
contrib/hstore_plpython/hstore_plpython.c | 116 +
contrib/hstore_plpython/hstore_plpython2u--1.0.sql | 19 +
contrib/hstore_plpython/hstore_plpython2u.control | 6 +
contrib/hstore_plpython/hstore_plpython3u--1.0.sql | 19 +
contrib/hstore_plpython/hstore_plpython3u.control | 6 +
contrib/hstore_plpython/hstore_plpythonu--1.0.sql | 19 +
contrib/hstore_plpython/hstore_plpythonu.control | 6 +
contrib/hstore_plpython/sql/hstore_plpython.sql | 103 +
contrib/ltree_plpython/.gitignore | 6 +
contrib/ltree_plpython/Makefile | 31 +
contrib/ltree_plpython/expected/ltree_plpython.out | 45 +
contrib/ltree_plpython/ltree_plpython.c | 32 +
contrib/ltree_plpython/ltree_plpython2u--1.0.sql | 12 +
contrib/ltree_plpython/ltree_plpython2u.control | 6 +
contrib/ltree_plpython/ltree_plpython3u--1.0.sql | 12 +
contrib/ltree_plpython/ltree_plpython3u.control | 6 +
contrib/ltree_plpython/ltree_plpythonu--1.0.sql | 12 +
contrib/ltree_plpython/ltree_plpythonu.control | 6 +
contrib/ltree_plpython/sql/ltree_plpython.sql | 37 +
doc/src/sgml/catalogs.sgml | 82 +
doc/src/sgml/hstore.sgml | 19 +
doc/src/sgml/information_schema.sgml | 85 +
doc/src/sgml/ltree.sgml | 15 +
doc/src/sgml/ref/allfiles.sgml | 2 +
doc/src/sgml/ref/alter_extension.sgml | 21 +
doc/src/sgml/ref/comment.sgml | 22 +
doc/src/sgml/ref/create_function.sgml | 18 +
doc/src/sgml/ref/create_transform.sgml | 207 +
doc/src/sgml/ref/drop_transform.sgml | 123 +
doc/src/sgml/reference.sgml | 2 +
src/Makefile.shlib | 2 +-
src/backend/catalog/Makefile | 1 +
src/backend/catalog/dependency.c | 8 +
src/backend/catalog/information_schema.sql | 34 +-
src/backend/catalog/objectaddress.c | 65 +-
src/backend/catalog/pg_aggregate.c | 1 +
src/backend/catalog/pg_proc.c | 46 +-
src/backend/commands/dropcmds.c | 8 +
src/backend/commands/event_trigger.c | 3 +
src/backend/commands/functioncmds.c | 343 +-
src/backend/commands/proclang.c | 3 +
src/backend/commands/typecmds.c | 1 +
src/backend/nodes/copyfuncs.c | 17 +
src/backend/nodes/equalfuncs.c | 15 +
src/backend/parser/gram.y | 90 +-
src/backend/tcop/utility.c | 16 +
src/backend/utils/adt/ruleutils.c | 39 +-
src/backend/utils/cache/lsyscache.c | 71 +
src/backend/utils/cache/syscache.c | 23 +
src/backend/utils/fmgr/funcapi.c | 44 +
src/bin/pg_dump/common.c | 5 +
src/bin/pg_dump/pg_dump.c | 273 +-
src/bin/pg_dump/pg_dump.h | 11 +
src/bin/pg_dump/pg_dump_sort.c | 11 +-
src/include/catalog/catversion.h | 2 +-
src/include/catalog/dependency.h | 1 +
src/include/catalog/indexing.h | 5 +
src/include/catalog/pg_class.h | 2 +-
src/include/catalog/pg_proc.h | 5382 ++++++++++----------
src/include/catalog/pg_proc_fn.h | 3 +
src/include/catalog/pg_transform.h | 47 +
src/include/commands/defrem.h | 3 +
src/include/funcapi.h | 1 +
src/include/nodes/nodes.h | 1 +
src/include/nodes/parsenodes.h | 15 +
src/include/parser/kwlist.h | 2 +
src/include/utils/lsyscache.h | 3 +
src/include/utils/syscache.h | 2 +
src/interfaces/ecpg/preproc/ecpg.tokens | 2 +-
src/interfaces/ecpg/preproc/ecpg.trailer | 5 +-
src/interfaces/ecpg/preproc/ecpg_keywords.c | 2 -
src/pl/plperl/GNUmakefile | 4 +-
src/pl/plperl/plperl.c | 47 +-
src/pl/plperl/plperl_helpers.h | 2 +
src/pl/plpython/Makefile | 40 +-
src/pl/plpython/plpy_main.c | 1 +
src/pl/plpython/plpy_procedure.c | 43 +-
src/pl/plpython/plpy_procedure.h | 2 +
src/pl/plpython/plpy_spi.c | 3 +-
src/pl/plpython/plpy_typeio.c | 159 +-
src/pl/plpython/plpy_typeio.h | 9 +-
src/pl/plpython/plpy_util.c | 21 +-
src/pl/plpython/plpy_util.h | 1 +
src/pl/plpython/plpython.h | 1 +
src/pl/plpython/regress-python3-mangle.mk | 35 +
src/test/regress/expected/sanity_check.out | 1 +
101 files changed, 6061 insertions(+), 2838 deletions(-)
--
Sent via pgsql-committers mailing list (pgsql-committers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-committers
^ permalink raw reply [nested|flat] 28+ messages in thread
* Re: pgsql: Add transforms feature
2015-04-26 14:53 pgsql: Add transforms feature Peter Eisentraut <peter_e@gmx.net>
@ 2015-04-26 16:36 ` Tom Lane <tgl@sss.pgh.pa.us>
2015-04-27 06:23 ` Re: pgsql: Add transforms feature Michael Paquier <michael.paquier@gmail.com>
2015-05-02 14:58 ` Re: pgsql: Add transforms feature Peter Eisentraut <peter_e@gmx.net>
1 sibling, 2 replies; 28+ messages in thread
From: Tom Lane @ 2015-04-26 16:36 UTC (permalink / raw)
To: Peter Eisentraut <peter_e@gmx.net>; +Cc: pgsql-committers
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
^ permalink raw reply [nested|flat] 28+ messages in thread
* Re: pgsql: Add transforms feature
2015-04-26 14:53 pgsql: Add transforms feature Peter Eisentraut <peter_e@gmx.net>
2015-04-26 16:36 ` Re: pgsql: Add transforms feature Tom Lane <tgl@sss.pgh.pa.us>
@ 2015-04-27 06:23 ` Michael Paquier <michael.paquier@gmail.com>
2015-04-27 12:21 ` Re: pgsql: Add transforms feature Peter Eisentraut <peter_e@gmx.net>
1 sibling, 1 reply; 28+ messages in thread
From: Michael Paquier @ 2015-04-27 06:23 UTC (permalink / raw)
To: Tom Lane <tgl@sss.pgh.pa.us>; +Cc: Peter Eisentraut <peter_e@gmx.net>; 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
^ permalink raw reply [nested|flat] 28+ messages in thread
* Re: pgsql: Add transforms feature
2015-04-26 14:53 pgsql: Add transforms feature Peter Eisentraut <peter_e@gmx.net>
2015-04-26 16:36 ` Re: pgsql: Add transforms feature Tom Lane <tgl@sss.pgh.pa.us>
2015-04-27 06:23 ` Re: pgsql: Add transforms feature Michael Paquier <michael.paquier@gmail.com>
@ 2015-04-27 12:21 ` Peter Eisentraut <peter_e@gmx.net>
2015-04-27 23:54 ` Re: pgsql: Add transforms feature Andrew Dunstan <andrew@dunslane.net>
0 siblings, 1 reply; 28+ messages in thread
From: Peter Eisentraut @ 2015-04-27 12:21 UTC (permalink / raw)
To: Michael Paquier <michael.paquier@gmail.com>; Tom Lane <tgl@sss.pgh.pa.us>; +Cc: 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
^ permalink raw reply [nested|flat] 28+ messages in thread
* Re: pgsql: Add transforms feature
2015-04-26 14:53 pgsql: Add transforms feature Peter Eisentraut <peter_e@gmx.net>
2015-04-26 16:36 ` Re: pgsql: Add transforms feature Tom Lane <tgl@sss.pgh.pa.us>
2015-04-27 06:23 ` Re: pgsql: Add transforms feature Michael Paquier <michael.paquier@gmail.com>
2015-04-27 12:21 ` Re: pgsql: Add transforms feature Peter Eisentraut <peter_e@gmx.net>
@ 2015-04-27 23:54 ` Andrew Dunstan <andrew@dunslane.net>
2015-04-28 00:55 ` Re: pgsql: Add transforms feature Andrew Dunstan <andrew@dunslane.net>
0 siblings, 1 reply; 28+ messages in thread
From: Andrew Dunstan @ 2015-04-27 23:54 UTC (permalink / raw)
To: Peter Eisentraut <peter_e@gmx.net>; Michael Paquier <michael.paquier@gmail.com>; Tom Lane <tgl@sss.pgh.pa.us>; +Cc: 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
^ permalink raw reply [nested|flat] 28+ messages in thread
* Re: pgsql: Add transforms feature
2015-04-26 14:53 pgsql: Add transforms feature Peter Eisentraut <peter_e@gmx.net>
2015-04-26 16:36 ` Re: pgsql: Add transforms feature Tom Lane <tgl@sss.pgh.pa.us>
2015-04-27 06:23 ` Re: pgsql: Add transforms feature Michael Paquier <michael.paquier@gmail.com>
2015-04-27 12:21 ` Re: pgsql: Add transforms feature Peter Eisentraut <peter_e@gmx.net>
2015-04-27 23:54 ` Re: pgsql: Add transforms feature Andrew Dunstan <andrew@dunslane.net>
@ 2015-04-28 00:55 ` Andrew Dunstan <andrew@dunslane.net>
2015-04-28 01:01 ` Re: pgsql: Add transforms feature Michael Paquier <michael.paquier@gmail.com>
0 siblings, 1 reply; 28+ messages in thread
From: Andrew Dunstan @ 2015-04-28 00:55 UTC (permalink / raw)
To: Peter Eisentraut <peter_e@gmx.net>; Michael Paquier <michael.paquier@gmail.com>; Tom Lane <tgl@sss.pgh.pa.us>; +Cc: 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
^ permalink raw reply [nested|flat] 28+ messages in thread
* Re: pgsql: Add transforms feature
2015-04-26 14:53 pgsql: Add transforms feature Peter Eisentraut <peter_e@gmx.net>
2015-04-26 16:36 ` Re: pgsql: Add transforms feature Tom Lane <tgl@sss.pgh.pa.us>
2015-04-27 06:23 ` Re: pgsql: Add transforms feature Michael Paquier <michael.paquier@gmail.com>
2015-04-27 12:21 ` Re: pgsql: Add transforms feature Peter Eisentraut <peter_e@gmx.net>
2015-04-27 23:54 ` Re: pgsql: Add transforms feature Andrew Dunstan <andrew@dunslane.net>
2015-04-28 00:55 ` Re: pgsql: Add transforms feature Andrew Dunstan <andrew@dunslane.net>
@ 2015-04-28 01:01 ` Michael Paquier <michael.paquier@gmail.com>
2015-04-28 13:04 ` Re: pgsql: Add transforms feature Michael Paquier <michael.paquier@gmail.com>
0 siblings, 1 reply; 28+ messages in thread
From: Michael Paquier @ 2015-04-28 01:01 UTC (permalink / raw)
To: Andrew Dunstan <andrew@dunslane.net>; +Cc: Peter Eisentraut <peter_e@gmx.net>; Tom Lane <tgl@sss.pgh.pa.us>; 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
^ permalink raw reply [nested|flat] 28+ messages in thread
* Re: pgsql: Add transforms feature
2015-04-26 14:53 pgsql: Add transforms feature Peter Eisentraut <peter_e@gmx.net>
2015-04-26 16:36 ` Re: pgsql: Add transforms feature Tom Lane <tgl@sss.pgh.pa.us>
2015-04-27 06:23 ` Re: pgsql: Add transforms feature Michael Paquier <michael.paquier@gmail.com>
2015-04-27 12:21 ` Re: pgsql: Add transforms feature Peter Eisentraut <peter_e@gmx.net>
2015-04-27 23:54 ` Re: pgsql: Add transforms feature Andrew Dunstan <andrew@dunslane.net>
2015-04-28 00:55 ` Re: pgsql: Add transforms feature Andrew Dunstan <andrew@dunslane.net>
2015-04-28 01:01 ` Re: pgsql: Add transforms feature Michael Paquier <michael.paquier@gmail.com>
@ 2015-04-28 13:04 ` Michael Paquier <michael.paquier@gmail.com>
2015-04-28 15:51 ` Re: pgsql: Add transforms feature Andrew Dunstan <andrew@dunslane.net>
0 siblings, 1 reply; 28+ messages in thread
From: Michael Paquier @ 2015-04-28 13:04 UTC (permalink / raw)
To: Andrew Dunstan <andrew@dunslane.net>; +Cc: Peter Eisentraut <peter_e@gmx.net>; Tom Lane <tgl@sss.pgh.pa.us>; 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
--
Sent via pgsql-committers mailing list (pgsql-committers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-committers
Attachments: download all (2 files, .tar.gz)
0001-Fix-MSVC-build-for-transform-modules.patch (application/x-patch, 13.2K) download
From dedbdb5815b3b0450fcf6991156eb8ae022bd04a Mon Sep 17 00:00:00 2001
From: Michael Paquier <michael@otacoo.com>
Date: Tue, 28 Apr 2015 02:13:47 -0700
Subject: [PATCH 1/2] Fix MSVC build for transform modules
The following contrib/ modules have their build fixed in the MSVC scripts:
- hstore_plperl
- hstore_plpython
- ltree_plpython
With this patch the MSVC build and installation will work correctly with
the transforms. However their test is still disabled as some adjustments
are needed for plpython transforms.
---
src/tools/msvc/Install.pm | 9 +-
src/tools/msvc/Mkvcbuild.pm | 314 ++++++++++++++++++++++++++++----------------
src/tools/msvc/vcregress.pl | 10 +-
3 files changed, 212 insertions(+), 121 deletions(-)
diff --git a/src/tools/msvc/Install.pm b/src/tools/msvc/Install.pm
index bfcdf50..b617835 100644
--- a/src/tools/msvc/Install.pm
+++ b/src/tools/msvc/Install.pm
@@ -439,9 +439,12 @@ sub CopyContribFiles
while (my $d = readdir($D))
{
# These configuration-based exclusions must match vcregress.pl
- next if ($d eq "uuid-ossp" && !defined($config->{uuid}));
- next if ($d eq "sslinfo" && !defined($config->{openssl}));
- next if ($d eq "xml2" && !defined($config->{xml}));
+ next if ($d eq "uuid-ossp" && !defined($config->{uuid}));
+ next if ($d eq "sslinfo" && !defined($config->{openssl}));
+ next if ($d eq "xml2" && !defined($config->{xml}));
+ next if ($d eq "hstore_plperl" && !defined($config->{perl}));
+ next if ($d eq "hstore_plpython" && !defined($config->{python}));
+ next if ($d eq "ltree_plpython" && !defined($config->{python}));
next if ($d eq "sepgsql");
CopySubdirFiles($subdir, $d, $config, $target);
diff --git a/src/tools/msvc/Mkvcbuild.pm b/src/tools/msvc/Mkvcbuild.pm
index cfb9b24..9d66368 100644
--- a/src/tools/msvc/Mkvcbuild.pm
+++ b/src/tools/msvc/Mkvcbuild.pm
@@ -46,7 +46,11 @@ my $contrib_extraincludes =
my $contrib_extrasource = {
'cube' => [ 'contrib/cube/cubescan.l', 'contrib/cube/cubeparse.y' ],
'seg' => [ 'contrib/seg/segscan.l', 'contrib/seg/segparse.y' ], };
-my @contrib_excludes = ('pgcrypto', 'commit_ts', 'intagg', 'sepgsql');
+my @contrib_excludes = (
+ 'commit_ts', 'hstore_plperl',
+ 'hstore_plpython', 'intagg',
+ 'ltree_plpython', 'pgcrypto',
+ 'sepgsql');
# Set of variables for frontend modules
my $frontend_defines = { 'initdb' => 'FRONTEND' };
@@ -176,119 +180,6 @@ sub mkvcbuild
$plpgsql->AddFiles('src/pl/plpgsql/src', 'pl_gram.y');
$plpgsql->AddReference($postgres);
- if ($solution->{options}->{perl})
- {
- my $plperlsrc = "src/pl/plperl/";
- my $plperl =
- $solution->AddProject('plperl', 'dll', 'PLs', 'src/pl/plperl');
- $plperl->AddIncludeDir($solution->{options}->{perl} . '/lib/CORE');
- $plperl->AddDefine('PLPERL_HAVE_UID_GID');
- foreach my $xs ('SPI.xs', 'Util.xs')
- {
- (my $xsc = $xs) =~ s/\.xs/.c/;
- if (Solution::IsNewer("$plperlsrc$xsc", "$plperlsrc$xs"))
- {
- my $xsubppdir = first { -e "$_/ExtUtils/xsubpp" } @INC;
- print "Building $plperlsrc$xsc...\n";
- system( $solution->{options}->{perl}
- . '/bin/perl '
- . "$xsubppdir/ExtUtils/xsubpp -typemap "
- . $solution->{options}->{perl}
- . '/lib/ExtUtils/typemap '
- . "$plperlsrc$xs "
- . ">$plperlsrc$xsc");
- if ((!(-f "$plperlsrc$xsc")) || -z "$plperlsrc$xsc")
- {
- unlink("$plperlsrc$xsc"); # if zero size
- die "Failed to create $xsc.\n";
- }
- }
- }
- if (Solution::IsNewer(
- 'src/pl/plperl/perlchunks.h',
- 'src/pl/plperl/plc_perlboot.pl')
- || Solution::IsNewer(
- 'src/pl/plperl/perlchunks.h',
- 'src/pl/plperl/plc_trusted.pl'))
- {
- print 'Building src/pl/plperl/perlchunks.h ...' . "\n";
- my $basedir = getcwd;
- chdir 'src/pl/plperl';
- system( $solution->{options}->{perl}
- . '/bin/perl '
- . 'text2macro.pl '
- . '--strip="^(\#.*|\s*)$$" '
- . 'plc_perlboot.pl plc_trusted.pl '
- . '>perlchunks.h');
- chdir $basedir;
- if ((!(-f 'src/pl/plperl/perlchunks.h'))
- || -z 'src/pl/plperl/perlchunks.h')
- {
- unlink('src/pl/plperl/perlchunks.h'); # if zero size
- die 'Failed to create perlchunks.h' . "\n";
- }
- }
- if (Solution::IsNewer(
- 'src/pl/plperl/plperl_opmask.h',
- 'src/pl/plperl/plperl_opmask.pl'))
- {
- print 'Building src/pl/plperl/plperl_opmask.h ...' . "\n";
- my $basedir = getcwd;
- chdir 'src/pl/plperl';
- system( $solution->{options}->{perl}
- . '/bin/perl '
- . 'plperl_opmask.pl '
- . 'plperl_opmask.h');
- chdir $basedir;
- if ((!(-f 'src/pl/plperl/plperl_opmask.h'))
- || -z 'src/pl/plperl/plperl_opmask.h')
- {
- unlink('src/pl/plperl/plperl_opmask.h'); # if zero size
- die 'Failed to create plperl_opmask.h' . "\n";
- }
- }
- $plperl->AddReference($postgres);
- my @perl_libs =
- grep { /perl\d+.lib$/ }
- glob($solution->{options}->{perl} . '\lib\CORE\perl*.lib');
- if (@perl_libs == 1)
- {
- $plperl->AddLibrary($perl_libs[0]);
- }
- else
- {
- die "could not identify perl library version";
- }
- }
-
- if ($solution->{options}->{python})
- {
-
- # Attempt to get python version and location.
- # Assume python.exe in specified dir.
- open(P,
- $solution->{options}->{python}
- . "\\python -c \"import sys;print(sys.prefix);print(str(sys.version_info[0])+str(sys.version_info[1]))\" |"
- ) || die "Could not query for python version!\n";
- my $pyprefix = <P>;
- chomp($pyprefix);
- my $pyver = <P>;
- chomp($pyver);
- close(P);
-
- # Sometimes (always?) if python is not present, the execution
- # appears to work, but gives no data...
- die "Failed to query python for version information\n"
- if (!(defined($pyprefix) && defined($pyver)));
-
- my $pymajorver = substr($pyver, 0, 1);
- my $plpython = $solution->AddProject('plpython' . $pymajorver,
- 'dll', 'PLs', 'src/pl/plpython');
- $plpython->AddIncludeDir($pyprefix . '/include');
- $plpython->AddLibrary($pyprefix . "/Libs/python$pyver.lib");
- $plpython->AddReference($postgres);
- }
-
if ($solution->{options}->{tcl})
{
my $pltcl =
@@ -571,6 +462,139 @@ sub mkvcbuild
closedir($D);
}
+ # Build Perl and Python modules after contrib/ modules to satisfy some
+ # dependencies with transform contrib modules, like hstore_plpython
+ # ltree_plpython and hstore_plperl.
+ if ($solution->{options}->{python})
+ {
+ # Attempt to get python version and location.
+ # Assume python.exe in specified dir.
+ open(P,
+ $solution->{options}->{python}
+ . "\\python -c \"import sys;print(sys.prefix);print(str(sys.version_info[0])+str(sys.version_info[1]))\" |"
+ ) || die "Could not query for python version!\n";
+ my $pyprefix = <P>;
+ chomp($pyprefix);
+ my $pyver = <P>;
+ chomp($pyver);
+ close(P);
+
+ # Sometimes (always?) if python is not present, the execution
+ # appears to work, but gives no data...
+ die "Failed to query python for version information\n"
+ if (!(defined($pyprefix) && defined($pyver)));
+
+ my $pymajorver = substr($pyver, 0, 1);
+ my $pymajorver = substr($pyver, 0, 1);
+ my $plpython = $solution->AddProject('plpython' . $pymajorver,
+ 'dll', 'PLs', 'src/pl/plpython');
+ $plpython->AddIncludeDir($pyprefix . '/include');
+ $plpython->AddLibrary($pyprefix . "/Libs/python$pyver.lib");
+ $plpython->AddReference($postgres);
+
+ # Add transform modules dependent on plpython
+ AddTransformModule('hstore_plpython' . $pymajorver,
+ 'contrib/hstore_plpython',
+ 'plpython' . $pymajorver,
+ 'src/pl/plpython', 'hstore',
+ 'contrib/hstore');
+ AddTransformModule('ltree_plpython' . $pymajorver,
+ 'contrib/ltree_plpython',
+ 'plpython' . $pymajorver,
+ 'src/pl/plpython', 'ltree',
+ 'contrib/ltree');
+ }
+
+ if ($solution->{options}->{perl})
+ {
+ my $plperlsrc = "src/pl/plperl/";
+ my $plperl =
+ $solution->AddProject('plperl', 'dll', 'PLs', 'src/pl/plperl');
+ $plperl->AddIncludeDir($solution->{options}->{perl} . '/lib/CORE');
+ $plperl->AddDefine('PLPERL_HAVE_UID_GID');
+ foreach my $xs ('SPI.xs', 'Util.xs')
+ {
+ (my $xsc = $xs) =~ s/\.xs/.c/;
+ if (Solution::IsNewer("$plperlsrc$xsc", "$plperlsrc$xs"))
+ {
+ my $xsubppdir = first { -e "$_/ExtUtils/xsubpp" } @INC;
+ print "Building $plperlsrc$xsc...\n";
+ system( $solution->{options}->{perl}
+ . '/bin/perl '
+ . "$xsubppdir/ExtUtils/xsubpp -typemap "
+ . $solution->{options}->{perl}
+ . '/lib/ExtUtils/typemap '
+ . "$plperlsrc$xs "
+ . ">$plperlsrc$xsc");
+ if ((!(-f "$plperlsrc$xsc")) || -z "$plperlsrc$xsc")
+ {
+ unlink("$plperlsrc$xsc"); # if zero size
+ die "Failed to create $xsc.\n";
+ }
+ }
+ }
+ if (Solution::IsNewer(
+ 'src/pl/plperl/perlchunks.h',
+ 'src/pl/plperl/plc_perlboot.pl')
+ || Solution::IsNewer(
+ 'src/pl/plperl/perlchunks.h',
+ 'src/pl/plperl/plc_trusted.pl'))
+ {
+ print 'Building src/pl/plperl/perlchunks.h ...' . "\n";
+ my $basedir = getcwd;
+ chdir 'src/pl/plperl';
+ system( $solution->{options}->{perl}
+ . '/bin/perl '
+ . 'text2macro.pl '
+ . '--strip="^(\#.*|\s*)$$" '
+ . 'plc_perlboot.pl plc_trusted.pl '
+ . '>perlchunks.h');
+ chdir $basedir;
+ if ((!(-f 'src/pl/plperl/perlchunks.h'))
+ || -z 'src/pl/plperl/perlchunks.h')
+ {
+ unlink('src/pl/plperl/perlchunks.h'); # if zero size
+ die 'Failed to create perlchunks.h' . "\n";
+ }
+ }
+ if (Solution::IsNewer(
+ 'src/pl/plperl/plperl_opmask.h',
+ 'src/pl/plperl/plperl_opmask.pl'))
+ {
+ print 'Building src/pl/plperl/plperl_opmask.h ...' . "\n";
+ my $basedir = getcwd;
+ chdir 'src/pl/plperl';
+ system( $solution->{options}->{perl}
+ . '/bin/perl '
+ . 'plperl_opmask.pl '
+ . 'plperl_opmask.h');
+ chdir $basedir;
+ if ((!(-f 'src/pl/plperl/plperl_opmask.h'))
+ || -z 'src/pl/plperl/plperl_opmask.h')
+ {
+ unlink('src/pl/plperl/plperl_opmask.h'); # if zero size
+ die 'Failed to create plperl_opmask.h' . "\n";
+ }
+ }
+ $plperl->AddReference($postgres);
+ my @perl_libs =
+ grep { /perl\d+.lib$/ }
+ glob($solution->{options}->{perl} . '\lib\CORE\perl*.lib');
+ if (@perl_libs == 1)
+ {
+ $plperl->AddLibrary($perl_libs[0]);
+ }
+ else
+ {
+ die "could not identify perl library version";
+ }
+
+ # Add transform module dependent on plperl
+ AddTransformModule('hstore_plperl', 'contrib/hstore_plperl',
+ 'plperl', 'src/pl/plperl',
+ 'hstore', 'contrib/hstore');
+ }
+
$mf =
Project::read_file('src/backend/utils/mb/conversion_procs/Makefile');
$mf =~ s{\\\r?\n}{}g;
@@ -680,6 +704,68 @@ sub AddSimpleFrontend
return $p;
}
+# Add a simple transform module
+sub AddTransformModule
+{
+ my $n = shift;
+ my $n_src = shift;
+ my $pl_proj_name = shift;
+ my $pl_src = shift;
+ my $transform_name = shift;
+ my $transform_src = shift;
+
+ my $transform_proj = undef;
+ foreach my $proj (@{ $solution->{projects}->{'contrib'} })
+ {
+ if ($proj->{name} eq $transform_name)
+ {
+ $transform_proj = $proj;
+ last;
+ }
+ }
+ die "could not find base module $transform_name for transform module $n"
+ if (!defined($transform_proj));
+
+ my $pl_proj = undef;
+ foreach my $proj (@{ $solution->{projects}->{'PLs'} })
+ {
+ if ($proj->{name} eq $pl_proj_name)
+ {
+ $pl_proj = $proj;
+ last;
+ }
+ }
+ die "could not find PL $pl_proj_name for transform module $n"
+ if (!defined($pl_proj));
+
+ my $p = $solution->AddProject($n, 'dll', 'contrib', $n_src);
+ for my $file (glob("$n_src/*.c"))
+ {
+ $p->AddFile($file);
+ }
+ $p->AddReference($postgres);
+
+ # Add PL dependencies
+ $p->AddIncludeDir($pl_src);
+ $p->AddReference($pl_proj);
+ $p->AddIncludeDir($pl_proj->{includes});
+ foreach my $pl_lib (@{$pl_proj->{libraries}})
+ {
+ $p->AddLibrary($pl_lib);
+ }
+
+ # Add base module dependencies
+ $p->AddIncludeDir($transform_src);
+ $p->AddIncludeDir($transform_proj->{includes});
+ foreach my $trans_lib (@{$transform_proj->{libraries}})
+ {
+ $p->AddLibrary($trans_lib);
+ }
+ $p->AddReference($transform_proj);
+
+ return $p;
+}
+
# Add a simple contrib project
sub AddContrib
{
diff --git a/src/tools/msvc/vcregress.pl b/src/tools/msvc/vcregress.pl
index 0153f05..8c071a5 100644
--- a/src/tools/msvc/vcregress.pl
+++ b/src/tools/msvc/vcregress.pl
@@ -262,9 +262,12 @@ sub contribcheck
foreach my $module (glob("*"))
{
# these configuration-based exclusions must match Install.pm
- next if ($module eq "uuid-ossp" && !defined($config->{uuid}));
- next if ($module eq "sslinfo" && !defined($config->{openssl}));
- next if ($module eq "xml2" && !defined($config->{xml}));
+ next if ($module eq "uuid-ossp" && !defined($config->{uuid}));
+ next if ($module eq "sslinfo" && !defined($config->{openssl}));
+ next if ($module eq "xml2" && !defined($config->{xml}));
+ next if ($module eq "hstore_plperl" && !defined($config->{perl}));
+ next if ($module eq "hstore_plpython");
+ next if ($module eq "ltree_plpython");
next if ($module eq "sepgsql");
subdircheck("$topdir/contrib", $module);
@@ -375,7 +378,6 @@ sub fetchRegressOpts
$m =~ s{\\\r?\n}{}g;
if ($m =~ /^\s*REGRESS_OPTS\s*=(.*)/m)
{
-
# Substitute known Makefile variables, then ignore options that retain
# an unhandled variable reference. Ignore anything that isn't an
# option starting with "--".
--
2.3.6
0002-Enable-version-specific-tests-of-plpython-transforms.patch (application/x-patch, 2.1K) download
From 7aa4d458e9abed2569fe0cc69277d904b94b10fc Mon Sep 17 00:00:00 2001
From: Michael Paquier <michael@otacoo.com>
Date: Tue, 28 Apr 2015 05:53:49 -0700
Subject: [PATCH 2/2] Enable version-specific tests of plpython transforms in
MSVC
Those tests need to check for the version of Python available on system
in order to select the extensions that should be loaded for the tests.
---
src/tools/msvc/vcregress.pl | 29 +++++++++++++++++++++++++++--
1 file changed, 27 insertions(+), 2 deletions(-)
diff --git a/src/tools/msvc/vcregress.pl b/src/tools/msvc/vcregress.pl
index 8c071a5..92798dc 100644
--- a/src/tools/msvc/vcregress.pl
+++ b/src/tools/msvc/vcregress.pl
@@ -244,6 +244,31 @@ sub subdircheck
print "Checking $module\n";
my @tests = fetchTests();
my @opts = fetchRegressOpts();
+
+ # Add some options for transform modules, see their respective
+ # Makefile for more details regarding Python-version specific
+ # dependencies.
+ if ($module eq "hstore_plpython" ||
+ $module eq "ltree_plpython")
+ {
+ die "Python not enabled in configuration"
+ if !defined($config->{python});
+
+ # Get major version number of Python.
+ open(P,
+ $config->{python}
+ . "\\python -c \"import sys;print(str(sys.version_info[0]))\" |"
+ ) || die "Could not query for python version!\n";
+ my $pyver = <P>;
+ chomp($pyver);
+ close(P);
+ if ($pyver eq "2")
+ {
+ push @opts, "--load-extension=plpythonu";
+ push @opts, '--load-extension=' . $module . 'u';
+ }
+ }
+
my @args = (
"${tmp_installdir}/bin/pg_regress",
"--bindir=${tmp_installdir}/bin",
@@ -266,8 +291,8 @@ sub contribcheck
next if ($module eq "sslinfo" && !defined($config->{openssl}));
next if ($module eq "xml2" && !defined($config->{xml}));
next if ($module eq "hstore_plperl" && !defined($config->{perl}));
- next if ($module eq "hstore_plpython");
- next if ($module eq "ltree_plpython");
+ next if ($module eq "hstore_plpython" && !defined($config->{python}));
+ next if ($module eq "ltree_plpython" && !defined($config->{python}));
next if ($module eq "sepgsql");
subdircheck("$topdir/contrib", $module);
--
2.3.6
* Re: pgsql: Add transforms feature
2015-04-26 14:53 pgsql: Add transforms feature Peter Eisentraut <peter_e@gmx.net>
2015-04-26 16:36 ` Re: pgsql: Add transforms feature Tom Lane <tgl@sss.pgh.pa.us>
2015-04-27 06:23 ` Re: pgsql: Add transforms feature Michael Paquier <michael.paquier@gmail.com>
2015-04-27 12:21 ` Re: pgsql: Add transforms feature Peter Eisentraut <peter_e@gmx.net>
2015-04-27 23:54 ` Re: pgsql: Add transforms feature Andrew Dunstan <andrew@dunslane.net>
2015-04-28 00:55 ` Re: pgsql: Add transforms feature Andrew Dunstan <andrew@dunslane.net>
2015-04-28 01:01 ` Re: pgsql: Add transforms feature Michael Paquier <michael.paquier@gmail.com>
2015-04-28 13:04 ` Re: pgsql: Add transforms feature Michael Paquier <michael.paquier@gmail.com>
@ 2015-04-28 15:51 ` Andrew Dunstan <andrew@dunslane.net>
2015-04-28 16:03 ` Re: pgsql: Add transforms feature Andrew Dunstan <andrew@dunslane.net>
0 siblings, 1 reply; 28+ messages in thread
From: Andrew Dunstan @ 2015-04-28 15:51 UTC (permalink / raw)
To: Michael Paquier <michael.paquier@gmail.com>; +Cc: Peter Eisentraut <peter_e@gmx.net>; Tom Lane <tgl@sss.pgh.pa.us>; pgsql-committers
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
^ permalink raw reply [nested|flat] 28+ messages in thread
* Re: pgsql: Add transforms feature
2015-04-26 14:53 pgsql: Add transforms feature Peter Eisentraut <peter_e@gmx.net>
2015-04-26 16:36 ` Re: pgsql: Add transforms feature Tom Lane <tgl@sss.pgh.pa.us>
2015-04-27 06:23 ` Re: pgsql: Add transforms feature Michael Paquier <michael.paquier@gmail.com>
2015-04-27 12:21 ` Re: pgsql: Add transforms feature Peter Eisentraut <peter_e@gmx.net>
2015-04-27 23:54 ` Re: pgsql: Add transforms feature Andrew Dunstan <andrew@dunslane.net>
2015-04-28 00:55 ` Re: pgsql: Add transforms feature Andrew Dunstan <andrew@dunslane.net>
2015-04-28 01:01 ` Re: pgsql: Add transforms feature Michael Paquier <michael.paquier@gmail.com>
2015-04-28 13:04 ` Re: pgsql: Add transforms feature Michael Paquier <michael.paquier@gmail.com>
2015-04-28 15:51 ` Re: pgsql: Add transforms feature Andrew Dunstan <andrew@dunslane.net>
@ 2015-04-28 16:03 ` Andrew Dunstan <andrew@dunslane.net>
2015-04-28 16:51 ` Re: [COMMITTERS] pgsql: Add transforms feature Andrew Dunstan <andrew@dunslane.net>
2015-04-28 20:10 ` Re: [COMMITTERS] pgsql: Add transforms feature Andrew Dunstan <andrew@dunslane.net>
0 siblings, 2 replies; 28+ messages in thread
From: Andrew Dunstan @ 2015-04-28 16:03 UTC (permalink / raw)
To: Michael Paquier <michael.paquier@gmail.com>; +Cc: Peter Eisentraut <peter_e@gmx.net>; Tom Lane <tgl@sss.pgh.pa.us>; 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
^ permalink raw reply [nested|flat] 28+ messages in thread
* Re: [COMMITTERS] pgsql: Add transforms feature
2015-04-26 14:53 pgsql: Add transforms feature Peter Eisentraut <peter_e@gmx.net>
2015-04-26 16:36 ` Re: pgsql: Add transforms feature Tom Lane <tgl@sss.pgh.pa.us>
2015-04-27 06:23 ` Re: pgsql: Add transforms feature Michael Paquier <michael.paquier@gmail.com>
2015-04-27 12:21 ` Re: pgsql: Add transforms feature Peter Eisentraut <peter_e@gmx.net>
2015-04-27 23:54 ` Re: pgsql: Add transforms feature Andrew Dunstan <andrew@dunslane.net>
2015-04-28 00:55 ` Re: pgsql: Add transforms feature Andrew Dunstan <andrew@dunslane.net>
2015-04-28 01:01 ` Re: pgsql: Add transforms feature Michael Paquier <michael.paquier@gmail.com>
2015-04-28 13:04 ` Re: pgsql: Add transforms feature Michael Paquier <michael.paquier@gmail.com>
2015-04-28 15:51 ` Re: pgsql: Add transforms feature Andrew Dunstan <andrew@dunslane.net>
2015-04-28 16:03 ` Re: pgsql: Add transforms feature Andrew Dunstan <andrew@dunslane.net>
@ 2015-04-28 16:51 ` Andrew Dunstan <andrew@dunslane.net>
1 sibling, 0 replies; 28+ messages in thread
From: Andrew Dunstan @ 2015-04-28 16:51 UTC (permalink / raw)
To: PostgreSQL-development <pgsql-hackers@postgresql.org>
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
^ permalink raw reply [nested|flat] 28+ messages in thread
* Re: [COMMITTERS] pgsql: Add transforms feature
2015-04-26 14:53 pgsql: Add transforms feature Peter Eisentraut <peter_e@gmx.net>
2015-04-26 16:36 ` Re: pgsql: Add transforms feature Tom Lane <tgl@sss.pgh.pa.us>
2015-04-27 06:23 ` Re: pgsql: Add transforms feature Michael Paquier <michael.paquier@gmail.com>
2015-04-27 12:21 ` Re: pgsql: Add transforms feature Peter Eisentraut <peter_e@gmx.net>
2015-04-27 23:54 ` Re: pgsql: Add transforms feature Andrew Dunstan <andrew@dunslane.net>
2015-04-28 00:55 ` Re: pgsql: Add transforms feature Andrew Dunstan <andrew@dunslane.net>
2015-04-28 01:01 ` Re: pgsql: Add transforms feature Michael Paquier <michael.paquier@gmail.com>
2015-04-28 13:04 ` Re: pgsql: Add transforms feature Michael Paquier <michael.paquier@gmail.com>
2015-04-28 15:51 ` Re: pgsql: Add transforms feature Andrew Dunstan <andrew@dunslane.net>
2015-04-28 16:03 ` Re: pgsql: Add transforms feature Andrew Dunstan <andrew@dunslane.net>
@ 2015-04-28 20:10 ` Andrew Dunstan <andrew@dunslane.net>
2015-04-28 20:15 ` Re: [COMMITTERS] pgsql: Add transforms feature Peter Eisentraut <peter_e@gmx.net>
2015-04-29 18:30 ` Re: [COMMITTERS] pgsql: Add transforms feature Andrew Dunstan <andrew@dunslane.net>
1 sibling, 2 replies; 28+ messages in thread
From: Andrew Dunstan @ 2015-04-28 20:10 UTC (permalink / raw)
To: Michael Paquier <michael.paquier@gmail.com>; +Cc: Peter Eisentraut <peter_e@gmx.net>; Tom Lane <tgl@sss.pgh.pa.us>; Tom Lane <tgl@sss.pgh.pa.us>; PostgreSQL-development <pgsql-hackers@postgresql.org>
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
^ permalink raw reply [nested|flat] 28+ messages in thread
* Re: [COMMITTERS] pgsql: Add transforms feature
2015-04-26 14:53 pgsql: Add transforms feature Peter Eisentraut <peter_e@gmx.net>
2015-04-26 16:36 ` Re: pgsql: Add transforms feature Tom Lane <tgl@sss.pgh.pa.us>
2015-04-27 06:23 ` Re: pgsql: Add transforms feature Michael Paquier <michael.paquier@gmail.com>
2015-04-27 12:21 ` Re: pgsql: Add transforms feature Peter Eisentraut <peter_e@gmx.net>
2015-04-27 23:54 ` Re: pgsql: Add transforms feature Andrew Dunstan <andrew@dunslane.net>
2015-04-28 00:55 ` Re: pgsql: Add transforms feature Andrew Dunstan <andrew@dunslane.net>
2015-04-28 01:01 ` Re: pgsql: Add transforms feature Michael Paquier <michael.paquier@gmail.com>
2015-04-28 13:04 ` Re: pgsql: Add transforms feature Michael Paquier <michael.paquier@gmail.com>
2015-04-28 15:51 ` Re: pgsql: Add transforms feature Andrew Dunstan <andrew@dunslane.net>
2015-04-28 16:03 ` Re: pgsql: Add transforms feature Andrew Dunstan <andrew@dunslane.net>
2015-04-28 20:10 ` Re: [COMMITTERS] pgsql: Add transforms feature Andrew Dunstan <andrew@dunslane.net>
@ 2015-04-28 20:15 ` Peter Eisentraut <peter_e@gmx.net>
2015-04-29 04:47 ` Re: [COMMITTERS] pgsql: Add transforms feature Michael Paquier <michael.paquier@gmail.com>
1 sibling, 1 reply; 28+ messages in thread
From: Peter Eisentraut @ 2015-04-28 20:15 UTC (permalink / raw)
To: Andrew Dunstan <andrew@dunslane.net>; Michael Paquier <michael.paquier@gmail.com>; +Cc: Tom Lane <tgl@sss.pgh.pa.us>; PostgreSQL-development <pgsql-hackers@postgresql.org>
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
^ permalink raw reply [nested|flat] 28+ messages in thread
* Re: [COMMITTERS] pgsql: Add transforms feature
2015-04-26 14:53 pgsql: Add transforms feature Peter Eisentraut <peter_e@gmx.net>
2015-04-26 16:36 ` Re: pgsql: Add transforms feature Tom Lane <tgl@sss.pgh.pa.us>
2015-04-27 06:23 ` Re: pgsql: Add transforms feature Michael Paquier <michael.paquier@gmail.com>
2015-04-27 12:21 ` Re: pgsql: Add transforms feature Peter Eisentraut <peter_e@gmx.net>
2015-04-27 23:54 ` Re: pgsql: Add transforms feature Andrew Dunstan <andrew@dunslane.net>
2015-04-28 00:55 ` Re: pgsql: Add transforms feature Andrew Dunstan <andrew@dunslane.net>
2015-04-28 01:01 ` Re: pgsql: Add transforms feature Michael Paquier <michael.paquier@gmail.com>
2015-04-28 13:04 ` Re: pgsql: Add transforms feature Michael Paquier <michael.paquier@gmail.com>
2015-04-28 15:51 ` Re: pgsql: Add transforms feature Andrew Dunstan <andrew@dunslane.net>
2015-04-28 16:03 ` Re: pgsql: Add transforms feature Andrew Dunstan <andrew@dunslane.net>
2015-04-28 20:10 ` Re: [COMMITTERS] pgsql: Add transforms feature Andrew Dunstan <andrew@dunslane.net>
2015-04-28 20:15 ` Re: [COMMITTERS] pgsql: Add transforms feature Peter Eisentraut <peter_e@gmx.net>
@ 2015-04-29 04:47 ` Michael Paquier <michael.paquier@gmail.com>
0 siblings, 0 replies; 28+ messages in thread
From: Michael Paquier @ 2015-04-29 04:47 UTC (permalink / raw)
To: Peter Eisentraut <peter_e@gmx.net>; +Cc: Andrew Dunstan <andrew@dunslane.net>; Tom Lane <tgl@sss.pgh.pa.us>; PostgreSQL-development <pgsql-hackers@postgresql.org>
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
^ permalink raw reply [nested|flat] 28+ messages in thread
* Re: [COMMITTERS] pgsql: Add transforms feature
2015-04-26 14:53 pgsql: Add transforms feature Peter Eisentraut <peter_e@gmx.net>
2015-04-26 16:36 ` Re: pgsql: Add transforms feature Tom Lane <tgl@sss.pgh.pa.us>
2015-04-27 06:23 ` Re: pgsql: Add transforms feature Michael Paquier <michael.paquier@gmail.com>
2015-04-27 12:21 ` Re: pgsql: Add transforms feature Peter Eisentraut <peter_e@gmx.net>
2015-04-27 23:54 ` Re: pgsql: Add transforms feature Andrew Dunstan <andrew@dunslane.net>
2015-04-28 00:55 ` Re: pgsql: Add transforms feature Andrew Dunstan <andrew@dunslane.net>
2015-04-28 01:01 ` Re: pgsql: Add transforms feature Michael Paquier <michael.paquier@gmail.com>
2015-04-28 13:04 ` Re: pgsql: Add transforms feature Michael Paquier <michael.paquier@gmail.com>
2015-04-28 15:51 ` Re: pgsql: Add transforms feature Andrew Dunstan <andrew@dunslane.net>
2015-04-28 16:03 ` Re: pgsql: Add transforms feature Andrew Dunstan <andrew@dunslane.net>
2015-04-28 20:10 ` Re: [COMMITTERS] pgsql: Add transforms feature Andrew Dunstan <andrew@dunslane.net>
@ 2015-04-29 18:30 ` Andrew Dunstan <andrew@dunslane.net>
2015-04-29 21:55 ` Re: [COMMITTERS] pgsql: Add transforms feature Michael Paquier <michael.paquier@gmail.com>
1 sibling, 1 reply; 28+ messages in thread
From: Andrew Dunstan @ 2015-04-29 18:30 UTC (permalink / raw)
To: Michael Paquier <michael.paquier@gmail.com>; +Cc: Peter Eisentraut <peter_e@gmx.net>; Tom Lane <tgl@sss.pgh.pa.us>; PostgreSQL-development <pgsql-hackers@postgresql.org>
On 04/28/2015 04:10 PM, Andrew Dunstan wrote:
>
> 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.
>
>
OK, I fixed this as Michael suggested by installing the 64 bit python3
(it's a pity that python.org didn't offer that to me as a download on
their front page - that's a bit ugly).
However, when it came to running these tests that was a miserable
failure. And indeed, we don't run any regression tests for plpython3 on
MSVC.
So I committed this with just python2 tests enabled. All the buildfarm
MSVC hosts seem to be using python2 anyway.
Meanwhile, we have some work to do on the mingw/gcc side.
These changes help make some progress - they let compilation succeed for
hstore_plperl but I still get linkage failures. I suspect we need some
things marked for export that we haven't to be marked needed before.
inline patch 1: contrib/hstore_plperl/Makefile (+1/-2 lines) download inline-1.patch
diff --git a/contrib/hstore_plperl/Makefile b/contrib/hstore_plperl/Makefile
index ddf6036..81fe1af 100644
--- a/contrib/hstore_plperl/Makefile
+++ b/contrib/hstore_plperl/Makefile
@@ -3,7 +3,7 @@
MODULE_big = hstore_plperl
OBJS = hstore_plperl.o
-PG_CPPFLAGS = -I$(top_srcdir)/src/pl/plperl -I$(perl_archlibexp)/CORE
-I$(top_srcdir)/contrib/hstore
+PG_CPPFLAGS = -I$(top_srcdir)/src/pl/plperl -I$(top_srcdir)/contrib/hstore
EXTENSION = hstore_plperl hstore_plperlu
* Re: [COMMITTERS] pgsql: Add transforms feature
2015-04-26 14:53 pgsql: Add transforms feature Peter Eisentraut <peter_e@gmx.net>
2015-04-26 16:36 ` Re: pgsql: Add transforms feature Tom Lane <tgl@sss.pgh.pa.us>
2015-04-27 06:23 ` Re: pgsql: Add transforms feature Michael Paquier <michael.paquier@gmail.com>
2015-04-27 12:21 ` Re: pgsql: Add transforms feature Peter Eisentraut <peter_e@gmx.net>
2015-04-27 23:54 ` Re: pgsql: Add transforms feature Andrew Dunstan <andrew@dunslane.net>
2015-04-28 00:55 ` Re: pgsql: Add transforms feature Andrew Dunstan <andrew@dunslane.net>
2015-04-28 01:01 ` Re: pgsql: Add transforms feature Michael Paquier <michael.paquier@gmail.com>
2015-04-28 13:04 ` Re: pgsql: Add transforms feature Michael Paquier <michael.paquier@gmail.com>
2015-04-28 15:51 ` Re: pgsql: Add transforms feature Andrew Dunstan <andrew@dunslane.net>
2015-04-28 16:03 ` Re: pgsql: Add transforms feature Andrew Dunstan <andrew@dunslane.net>
2015-04-28 20:10 ` Re: [COMMITTERS] pgsql: Add transforms feature Andrew Dunstan <andrew@dunslane.net>
2015-04-29 18:30 ` Re: [COMMITTERS] pgsql: Add transforms feature Andrew Dunstan <andrew@dunslane.net>
@ 2015-04-29 21:55 ` Michael Paquier <michael.paquier@gmail.com>
0 siblings, 0 replies; 28+ messages in thread
From: Michael Paquier @ 2015-04-29 21:55 UTC (permalink / raw)
To: Andrew Dunstan <andrew@dunslane.net>; +Cc: Peter Eisentraut <peter_e@gmx.net>; Tom Lane <tgl@sss.pgh.pa.us>; PostgreSQL-development <pgsql-hackers@postgresql.org>
On Thu, Apr 30, 2015 at 3:30 AM, Andrew Dunstan <andrew@dunslane.net> wrote:
>
> On 04/28/2015 04:10 PM, Andrew Dunstan wrote:
>>
>>
>> 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.
>>
>>
>
> OK, I fixed this as Michael suggested by installing the 64 bit python3 (it's
> a pity that python.org didn't offer that to me as a download on their front
> page - that's a bit ugly).
>
> However, when it came to running these tests that was a miserable failure.
> And indeed, we don't run any regression tests for plpython3 on MSVC.
I arrived to the same conclusion. Perhaps we shall write a TODO in the
code or on the wiki to not forget about that..
> So I committed this with just python2 tests enabled. All the buildfarm MSVC
> hosts seem to be using python2 anyway.
OK, thanks.
> Meanwhile, we have some work to do on the mingw/gcc side.
>
> These changes help make some progress - they let compilation succeed for
> hstore_plperl but I still get linkage failures. I suspect we need some
> things marked for export that we haven't to be marked needed before.
>
> [...]
I'll try to have a look at that a bit if possible...
Regards,
--
Michael
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
^ permalink raw reply [nested|flat] 28+ messages in thread
* Re: pgsql: Add transforms feature
2015-04-26 14:53 pgsql: Add transforms feature Peter Eisentraut <peter_e@gmx.net>
2015-04-26 16:36 ` Re: pgsql: Add transforms feature Tom Lane <tgl@sss.pgh.pa.us>
@ 2015-05-02 14:58 ` Peter Eisentraut <peter_e@gmx.net>
2015-05-03 18:27 ` Re: [COMMITTERS] pgsql: Add transforms feature Tom Lane <tgl@sss.pgh.pa.us>
2015-05-03 21:03 ` Re: pgsql: Add transforms feature Tom Lane <tgl@sss.pgh.pa.us>
1 sibling, 2 replies; 28+ messages in thread
From: Peter Eisentraut @ 2015-05-02 14:58 UTC (permalink / raw)
To: Tom Lane <tgl@sss.pgh.pa.us>; +Cc: pgsql-committers
On 4/26/15 12:36 PM, Tom Lane wrote:
> I don't know why this patch is fooling around with compile/link flags,
> but it's broken at least prairiedog
The addition of the link flag -undefined dynamic_lookup is so that
plugins can refer to symbols from other plugins. This is how other
platforms work by default, and it is standard for OS X in GNU libtool
and many other projects. I'm confused why prairiedog is complaining
about that. According to Internet lore, this flag seems to be available
from OS X either 10.3 or 10.1. prairiedog is listed as 10.4, but errors
with
MACOSX_DEPLOYMENT_TARGET environment variable set to: 10.1
Some of the above-mentioned other projects appear to have some OS X
version test, so we could do something like that. But before we embark
on that, could you clarify whether the build farm entry lists the
correct version?
--
Sent via pgsql-committers mailing list (pgsql-committers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-committers
^ permalink raw reply [nested|flat] 28+ messages in thread
* Re: [COMMITTERS] pgsql: Add transforms feature
2015-04-26 14:53 pgsql: Add transforms feature Peter Eisentraut <peter_e@gmx.net>
2015-04-26 16:36 ` Re: pgsql: Add transforms feature Tom Lane <tgl@sss.pgh.pa.us>
2015-05-02 14:58 ` Re: pgsql: Add transforms feature Peter Eisentraut <peter_e@gmx.net>
@ 2015-05-03 18:27 ` Tom Lane <tgl@sss.pgh.pa.us>
2015-05-06 02:24 ` Re: [COMMITTERS] pgsql: Add transforms feature Peter Eisentraut <peter_e@gmx.net>
1 sibling, 1 reply; 28+ messages in thread
From: Tom Lane @ 2015-05-03 18:27 UTC (permalink / raw)
To: Peter Eisentraut <peter_e@gmx.net>; +Cc: pgsql-hackers@postgreSQL.org
Peter Eisentraut <peter_e@gmx.net> writes:
> On 4/26/15 12:36 PM, Tom Lane wrote:
>> I don't know why this patch is fooling around with compile/link flags,
>> but it's broken at least prairiedog
> The addition of the link flag -undefined dynamic_lookup is so that
> plugins can refer to symbols from other plugins. This is how other
> platforms work by default, and it is standard for OS X in GNU libtool
> and many other projects. I'm confused why prairiedog is complaining
> about that.
We could look into a fix for prairiedog's situation, but TBH I think that
that is going in 100% the wrong direction. I'm pretty desperately unhappy
with the design choice you've made here, for two reasons:
1. Preventing undefined-symbol errors at link time might be standard
according to some platforms, but it is not the universal default, and
I think there is no very good reason to assume that it is possible
everywhere. So I'm afraid that prairiedog is just the canary in the coal
mine, warning us about portability problems we're going to have with
other non-mainstream platforms not represented in the buildfarm.
2. Preventing undefined-symbol errors at link time will hide actual coding
errors, not only the intended cross-plugin reference cases. We have
repeatedly seen the buildfarm members that complain about this find actual
bugs that were missed on laxer platforms. Therefore I think that this
approach is going to lead to masking bugs that we'll find only by much
more expensive/painful means than noticing a buildfarm failure.
Surely there are other ways to deal with this requirement that don't
require forcing undefined symbols to be treated as valid. For instance,
our existing find_rendezvous_variable() infrastructure might offer a
usable solution for passing a function pointer from plugin A to plugin B.
Indeed, that's pretty much what it was invented for.
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
^ permalink raw reply [nested|flat] 28+ messages in thread
* Re: [COMMITTERS] pgsql: Add transforms feature
2015-04-26 14:53 pgsql: Add transforms feature Peter Eisentraut <peter_e@gmx.net>
2015-04-26 16:36 ` Re: pgsql: Add transforms feature Tom Lane <tgl@sss.pgh.pa.us>
2015-05-02 14:58 ` Re: pgsql: Add transforms feature Peter Eisentraut <peter_e@gmx.net>
2015-05-03 18:27 ` Re: [COMMITTERS] pgsql: Add transforms feature Tom Lane <tgl@sss.pgh.pa.us>
@ 2015-05-06 02:24 ` Peter Eisentraut <peter_e@gmx.net>
2015-05-08 15:27 ` Re: [COMMITTERS] pgsql: Add transforms feature Tom Lane <tgl@sss.pgh.pa.us>
0 siblings, 1 reply; 28+ messages in thread
From: Peter Eisentraut @ 2015-05-06 02:24 UTC (permalink / raw)
To: Tom Lane <tgl@sss.pgh.pa.us>; +Cc: pgsql-hackers@postgreSQL.org
On 5/3/15 2:27 PM, Tom Lane wrote:
> 1. Preventing undefined-symbol errors at link time might be standard
> according to some platforms, but it is not the universal default, and
> I think there is no very good reason to assume that it is possible
> everywhere. So I'm afraid that prairiedog is just the canary in the coal
> mine, warning us about portability problems we're going to have with
> other non-mainstream platforms not represented in the buildfarm.
I don't think this is an issue, for the following reasons:
Any dlopenable module will have undefined symbols, namely those that it
uses to call back into the executable that loads the module. The only
way it can know to not complain about those symbols is if we tell it
about that executable at build time. Our current shared library build
setup makes reference to the postgres executable only on three
platforms: Windows, OS X, AIX. All other platforms necessarily accept
all undefined symbols at build time. We already know that it can also
be made to work on Windows and OS X. I expect that we might need some
tweaking on AIX, but I'm quite sure it can be made to work there also,
because ...
More generally, the way to build a dlopenable module with GNU libtool is
libtool --mode=link gcc -module -o hello.la foo.lo hello.lo
This works on "all" platforms, for a very large value of "all". There
isn't even an option to make a reference to the loading executable.
As a side note, Perl and Python themselves don't even build without this
option, so even if such platforms existed, they couldn't install Perl or
Python as we know it, and so wouldn't be able to use these features.
> 2. Preventing undefined-symbol errors at link time will hide actual coding
> errors, not only the intended cross-plugin reference cases. We have
> repeatedly seen the buildfarm members that complain about this find actual
> bugs that were missed on laxer platforms. Therefore I think that this
> approach is going to lead to masking bugs that we'll find only by much
> more expensive/painful means than noticing a buildfarm failure.
I appreciate this issue, and I have actually done quite a bit of
research in the hope of being able to provide similar functionality on
other platforms. But on platforms such as Linux, there is no equivalent
option at all. That is, you cannot build a dlopenable module with the
provision to error on all undefined symbols
except those found, say, in the postgres binary. So there is no way to
make all platforms reasonably similar here.
Which leads to a social problem. This is a feature intended for
extension authors. Extension authors will just build their code on
Linux, and if it runs, they ship it. Not everyone (hardly anyone) has
the option of doing platform testing for extensions. So if some
non-mainstream platform is more picky than others, then the inevitable
result is that extensions are more likely to be broken on non-mainstream
platforms. This is already frequently the case for other reasons, with
"non-mainstream" effectively meaning anything other than the author's
own machine in some cases, it appears. We're not going to make this
better by maintaining platform-specific traps.
This issue already exists independent of this feature. If I want to
create an extension that adds some functionality to hstore or hll or
postgis, I'll just call their symbols, it works, I'll ship it. We don't
have any way to prevent this, because many mainstream platforms don't
have the required fine-grained undefined symbol controls.
And the extension authors' path of least resistance when faced with a
build failure report on OS X, say, is to just add an option to the link
command in their extension, it works, it ships.
Moreover, I'm not sure this error checking actually buys us much in
practice. A typoed symbol will be flagged by a compiler warning, and
any undefined symbol will be caught be the test suite as soon as the
module is loaded. So I can't imagine what those buildfarm complaints
are, although I'd be interested look into them the analyze the
circumstances if someone could point me to some concrete cases.
Nonetheless, if there is so much attachment to this behavior, there
might be a simple compromise. We keep the error checking on by default,
but allow a pgxs-level variable setting like SHLIB_ALLOW_UNDEFINED.
This would essentially be equivalent to the
I'll-just-hack-my-extension's-makefile approach mentioned above that
will inevitably happen, but that way we can document it and maintain
some level of control over it.
> Surely there are other ways to deal with this requirement that don't
> require forcing undefined symbols to be treated as valid. For instance,
> our existing find_rendezvous_variable() infrastructure might offer a
> usable solution for passing a function pointer from plugin A to plugin B.
> Indeed, that's pretty much what it was invented for.
The rendezvous variables were invented for a different problem, namely
that you can load modules in arbitrary order, and only the first guy
initializes a variable. That's not the functionality that we need.
Also, any such approach would likely entail casting all functions and
variables through common pointer types, which would lose all kinds of
compiler checking. (All rendezvous variables are void pointers.)
It would put quite a bit of extra burden on the authors of modules such
as hstore or postgis to not only maintain a list of exported functions
but also test those interfaces. Either they'd have to dogfood those
interfaces and replace calls like hstoreCheckKeyLen(...) by
((somecrazycast) myfunctionlookup(hstoreCheckKeyLen))(...), or they'd
have to maintain a parallel set of interfaces that they could only test
by implementing a separate mock user of those interfaces.
At the end of the day, you'll end up implementing a bad version of half
the dynamic linker again in anticipation of a problem we know nothing about.
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
^ permalink raw reply [nested|flat] 28+ messages in thread
* Re: [COMMITTERS] pgsql: Add transforms feature
2015-04-26 14:53 pgsql: Add transforms feature Peter Eisentraut <peter_e@gmx.net>
2015-04-26 16:36 ` Re: pgsql: Add transforms feature Tom Lane <tgl@sss.pgh.pa.us>
2015-05-02 14:58 ` Re: pgsql: Add transforms feature Peter Eisentraut <peter_e@gmx.net>
2015-05-03 18:27 ` Re: [COMMITTERS] pgsql: Add transforms feature Tom Lane <tgl@sss.pgh.pa.us>
2015-05-06 02:24 ` Re: [COMMITTERS] pgsql: Add transforms feature Peter Eisentraut <peter_e@gmx.net>
@ 2015-05-08 15:27 ` Tom Lane <tgl@sss.pgh.pa.us>
0 siblings, 0 replies; 28+ messages in thread
From: Tom Lane @ 2015-05-08 15:27 UTC (permalink / raw)
To: Peter Eisentraut <peter_e@gmx.net>; +Cc: pgsql-hackers@postgresql.org
Peter Eisentraut <peter_e@gmx.net> writes:
> On 5/3/15 2:27 PM, Tom Lane wrote:
>> 2. Preventing undefined-symbol errors at link time will hide actual coding
>> errors, not only the intended cross-plugin reference cases. We have
>> repeatedly seen the buildfarm members that complain about this find actual
>> bugs that were missed on laxer platforms. Therefore I think that this
>> approach is going to lead to masking bugs that we'll find only by much
>> more expensive/painful means than noticing a buildfarm failure.
> I appreciate this issue, and I have actually done quite a bit of
> research in the hope of being able to provide similar functionality on
> other platforms.
I agree that it's probably impractical to persuade toolchains to do this
if they don't want to. But that doesn't mean that it's a good idea to
remove the whole class of error checks on platforms where it *is* possible
to make the check. The entire reason that we have a buildfarm is, in
essence, to get the union of all checks that are possible on any supported
platform.
> Moreover, I'm not sure this error checking actually buys us much in
> practice. A typoed symbol will be flagged by a compiler warning, and
> any undefined symbol will be caught be the test suite as soon as the
> module is loaded. So I can't imagine what those buildfarm complaints
> are, although I'd be interested look into them the analyze the
> circumstances if someone could point me to some concrete cases.
On many platforms, undefined symbols will only be complained of if you
actually try to call them, so I think this position places undue faith
in the code coverage of our buildfarm tests. (As a counterexample,
consider SSL, which I don't think we're exercising at all in the
buildfarm because of the difficulty of setup. And we have had bugs of
this sort versus OpenSSL, cf commit c9e1ad7fa.)
>> Surely there are other ways to deal with this requirement that don't
>> require forcing undefined symbols to be treated as valid. For instance,
>> our existing find_rendezvous_variable() infrastructure might offer a
>> usable solution for passing a function pointer from plugin A to plugin B.
> The rendezvous variables were invented for a different problem, namely
> that you can load modules in arbitrary order, and only the first guy
> initializes a variable. That's not the functionality that we need.
Sure it is. Look at what plpgsql uses it for: to export a
"PLpgSQL_plugin" struct containing function pointers that might be used
by other extensions. That seems to me to be exactly the same case as
what we're talking about here.
> Also, any such approach would likely entail casting all functions and
> variables through common pointer types, which would lose all kinds of
> compiler checking. (All rendezvous variables are void pointers.)
Only with very poor coding style. Properly declared function pointers
are pretty type-safe.
> It would put quite a bit of extra burden on the authors of modules such
> as hstore or postgis to not only maintain a list of exported functions
> but also test those interfaces.
Well, that actually gets to the core of my point: if a module author
exports a struct full of function pointers then he has put a stake in the
ground as to exactly what his exported API *is*. With what you've done
for transforms, what is the exported API of hstore or plpython or plperl?
Conceivably, any non-static function in those libraries is now fair game
for somebody else to call. We have this problem already with respect to
the core code, and it's nasty. We should not be encouraging the same
situation to develop for extensions.
I do not understand the second part of your point. Surely, if an
extension author expects other extensions to call function X, he's got the
same testing problem regardless of how the other extensions would reach X
exactly.
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
^ permalink raw reply [nested|flat] 28+ messages in thread
* Re: pgsql: Add transforms feature
2015-04-26 14:53 pgsql: Add transforms feature Peter Eisentraut <peter_e@gmx.net>
2015-04-26 16:36 ` Re: pgsql: Add transforms feature Tom Lane <tgl@sss.pgh.pa.us>
2015-05-02 14:58 ` Re: pgsql: Add transforms feature Peter Eisentraut <peter_e@gmx.net>
@ 2015-05-03 21:03 ` Tom Lane <tgl@sss.pgh.pa.us>
2015-05-03 21:37 ` Re: pgsql: Add transforms feature Tom Lane <tgl@sss.pgh.pa.us>
1 sibling, 1 reply; 28+ messages in thread
From: Tom Lane @ 2015-05-03 21:03 UTC (permalink / raw)
To: Peter Eisentraut <peter_e@gmx.net>; +Cc: pgsql-committers
Peter Eisentraut <peter_e@gmx.net> writes:
> ... I'm confused why prairiedog is complaining
> about that. According to Internet lore, this flag seems to be available
> from OS X either 10.3 or 10.1. prairiedog is listed as 10.4, but errors
> with
> MACOSX_DEPLOYMENT_TARGET environment variable set to: 10.1
> Some of the above-mentioned other projects appear to have some OS X
> version test, so we could do something like that. But before we embark
> on that, could you clarify whether the build farm entry lists the
> correct version?
So far as that goes, prairiedog is definitely running OS X 10.4.11.
I cannot find any sign that MACOSX_DEPLOYMENT_TARGET is explicitly set
anywhere. I resorted to grepping the entire filesystem, and found no
smoking gun but a few suggestive hits:
Binary file /usr/bin/ld matches
Binary file /usr/bin/powerpc-apple-darwin8-g++-4.0.1 matches
Binary file /usr/bin/powerpc-apple-darwin8-gcc-4.0.1 matches
/usr/share/aclocal/libtool.m4: case "${MACOSX_DEPLOYMENT_TARGET-10.1}" in
/usr/share/aclocal/libtool.m4: case "${MACOSX_DEPLOYMENT_TARGET-10.1}" in
/usr/share/aclocal/libtool.m4: case "${MACOSX_DEPLOYMENT_TARGET-10.1}" in
/usr/share/libtool/libltdl/acinclude.m4: case "${MACOSX_DEPLOYMENT_TARGET-10.1}" in
/usr/share/libtool/libltdl/acinclude.m4: case "${MACOSX_DEPLOYMENT_TARGET-10.1}" in
/usr/share/libtool/libltdl/acinclude.m4: case "${MACOSX_DEPLOYMENT_TARGET-10.1}" in
/usr/share/libtool/libltdl/aclocal.m4: case "${MACOSX_DEPLOYMENT_TARGET-10.1}" in
/usr/share/libtool/libltdl/aclocal.m4: case "${MACOSX_DEPLOYMENT_TARGET-10.1}" in
/usr/share/libtool/libltdl/aclocal.m4: case "${MACOSX_DEPLOYMENT_TARGET-10.1}" in
/usr/share/libtool/libltdl/configure: case "${MACOSX_DEPLOYMENT_TARGET-10.1}" in
/usr/share/libtool/libltdl/configure: case "${MACOSX_DEPLOYMENT_TARGET-10.1}" in
/usr/share/libtool/libltdl/configure: case "${MACOSX_DEPLOYMENT_TARGET-10.1}" in
/usr/share/libtool/libltdl/configure: case "${MACOSX_DEPLOYMENT_TARGET-10.1}" in
/usr/share/libtool/libltdl/configure: case "${MACOSX_DEPLOYMENT_TARGET-10.1}" in
This would explain libtool & libltdl defaulting to 10.1, but I wouldn't
have thought that we use either of those tools. Still, the file dates
on these files are comparable to the file dates on gcc and ld (viz late
2005/early 2006, which matches the window in which Tiger was current).
It would not be terribly surprising if there is an equivalent default
version assumption buried in those executables.
In short then, my best guess is that the 10.4-era build tools defaulted
to building 10.1-compatible product files unless you explicitly override
that by setting MACOSX_DEPLOYMENT_TARGET, which I haven't.
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
^ permalink raw reply [nested|flat] 28+ messages in thread
* Re: pgsql: Add transforms feature
2015-04-26 14:53 pgsql: Add transforms feature Peter Eisentraut <peter_e@gmx.net>
2015-04-26 16:36 ` Re: pgsql: Add transforms feature Tom Lane <tgl@sss.pgh.pa.us>
2015-05-02 14:58 ` Re: pgsql: Add transforms feature Peter Eisentraut <peter_e@gmx.net>
2015-05-03 21:03 ` Re: pgsql: Add transforms feature Tom Lane <tgl@sss.pgh.pa.us>
@ 2015-05-03 21:37 ` Tom Lane <tgl@sss.pgh.pa.us>
2015-05-03 22:27 ` Re: pgsql: Add transforms feature Tom Lane <tgl@sss.pgh.pa.us>
0 siblings, 1 reply; 28+ messages in thread
From: Tom Lane @ 2015-05-03 21:37 UTC (permalink / raw)
To: Peter Eisentraut <peter_e@gmx.net>; +Cc: pgsql-committers
I wrote:
> In short then, my best guess is that the 10.4-era build tools defaulted
> to building 10.1-compatible product files unless you explicitly override
> that by setting MACOSX_DEPLOYMENT_TARGET, which I haven't.
And indeed, explicitly setting MACOSX_DEPLOYMENT_TARGET = 10.4 gets
past the build failure. In the interests of getting the buildfarm
back to green, I've added that to the build environment spec for
prairiedog (we should have confirmation that it works in an hour or so).
However, I would really like this to be a temporary measure not the
permanent solution, for the reasons I gave earlier.
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
^ permalink raw reply [nested|flat] 28+ messages in thread
* Re: pgsql: Add transforms feature
2015-04-26 14:53 pgsql: Add transforms feature Peter Eisentraut <peter_e@gmx.net>
2015-04-26 16:36 ` Re: pgsql: Add transforms feature Tom Lane <tgl@sss.pgh.pa.us>
2015-05-02 14:58 ` Re: pgsql: Add transforms feature Peter Eisentraut <peter_e@gmx.net>
2015-05-03 21:03 ` Re: pgsql: Add transforms feature Tom Lane <tgl@sss.pgh.pa.us>
2015-05-03 21:37 ` Re: pgsql: Add transforms feature Tom Lane <tgl@sss.pgh.pa.us>
@ 2015-05-03 22:27 ` Tom Lane <tgl@sss.pgh.pa.us>
2015-05-03 22:49 ` Re: pgsql: Add transforms feature Andrew Dunstan <andrew@dunslane.net>
0 siblings, 1 reply; 28+ messages in thread
From: Tom Lane @ 2015-05-03 22:27 UTC (permalink / raw)
To: Peter Eisentraut <peter_e@gmx.net>; +Cc: pgsql-committers
I wrote:
> And indeed, explicitly setting MACOSX_DEPLOYMENT_TARGET = 10.4 gets
> past the build failure. In the interests of getting the buildfarm
> back to green, I've added that to the build environment spec for
> prairiedog (we should have confirmation that it works in an hour or so).
Well, it sort of works. Looks like the hstore_plpython test is expecting
some library function that Python 2.3 doesn't have.
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
^ permalink raw reply [nested|flat] 28+ messages in thread
* Re: pgsql: Add transforms feature
2015-04-26 14:53 pgsql: Add transforms feature Peter Eisentraut <peter_e@gmx.net>
2015-04-26 16:36 ` Re: pgsql: Add transforms feature Tom Lane <tgl@sss.pgh.pa.us>
2015-05-02 14:58 ` Re: pgsql: Add transforms feature Peter Eisentraut <peter_e@gmx.net>
2015-05-03 21:03 ` Re: pgsql: Add transforms feature Tom Lane <tgl@sss.pgh.pa.us>
2015-05-03 21:37 ` Re: pgsql: Add transforms feature Tom Lane <tgl@sss.pgh.pa.us>
2015-05-03 22:27 ` Re: pgsql: Add transforms feature Tom Lane <tgl@sss.pgh.pa.us>
@ 2015-05-03 22:49 ` Andrew Dunstan <andrew@dunslane.net>
2015-05-03 22:54 ` Re: pgsql: Add transforms feature Tom Lane <tgl@sss.pgh.pa.us>
0 siblings, 1 reply; 28+ messages in thread
From: Andrew Dunstan @ 2015-05-03 22:49 UTC (permalink / raw)
To: Tom Lane <tgl@sss.pgh.pa.us>; Peter Eisentraut <peter_e@gmx.net>; +Cc: pgsql-committers
On 05/03/2015 06:27 PM, Tom Lane wrote:
> I wrote:
>> And indeed, explicitly setting MACOSX_DEPLOYMENT_TARGET = 10.4 gets
>> past the build failure. In the interests of getting the buildfarm
>> back to green, I've added that to the build environment spec for
>> prairiedog (we should have confirmation that it works in an hour or so).
> Well, it sort of works. Looks like the hstore_plpython test is expecting
> some library function that Python 2.3 doesn't have.
>
>
I don't know if we have a standard for supported Python versions, but
Python 2.3.0 was released in 2003, and the last release in the series,
2.3.7 was released in March 2008. Is that really what ships on a modern OSX?
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
^ permalink raw reply [nested|flat] 28+ messages in thread
* Re: pgsql: Add transforms feature
2015-04-26 14:53 pgsql: Add transforms feature Peter Eisentraut <peter_e@gmx.net>
2015-04-26 16:36 ` Re: pgsql: Add transforms feature Tom Lane <tgl@sss.pgh.pa.us>
2015-05-02 14:58 ` Re: pgsql: Add transforms feature Peter Eisentraut <peter_e@gmx.net>
2015-05-03 21:03 ` Re: pgsql: Add transforms feature Tom Lane <tgl@sss.pgh.pa.us>
2015-05-03 21:37 ` Re: pgsql: Add transforms feature Tom Lane <tgl@sss.pgh.pa.us>
2015-05-03 22:27 ` Re: pgsql: Add transforms feature Tom Lane <tgl@sss.pgh.pa.us>
2015-05-03 22:49 ` Re: pgsql: Add transforms feature Andrew Dunstan <andrew@dunslane.net>
@ 2015-05-03 22:54 ` Tom Lane <tgl@sss.pgh.pa.us>
2015-05-03 23:41 ` Re: pgsql: Add transforms feature Andrew Dunstan <andrew@dunslane.net>
0 siblings, 1 reply; 28+ messages in thread
From: Tom Lane @ 2015-05-03 22:54 UTC (permalink / raw)
To: Andrew Dunstan <andrew@dunslane.net>; +Cc: Peter Eisentraut <peter_e@gmx.net>; pgsql-committers
Andrew Dunstan <andrew@dunslane.net> writes:
> On 05/03/2015 06:27 PM, Tom Lane wrote:
>> Well, it sort of works. Looks like the hstore_plpython test is expecting
>> some library function that Python 2.3 doesn't have.
> I don't know if we have a standard for supported Python versions, but
> Python 2.3.0 was released in 2003, and the last release in the series,
> 2.3.7 was released in March 2008. Is that really what ships on a modern OSX?
No, of course not; prairiedog is a very very trailing-edge box.
However, we explicitly claim support for Python >= 2.3 in the docs (see
installation.sgml), which is why prairiedog has that version and not
some other one. If we're going to move the goalposts on the minimum
supported version, it should be for a better reason than "I was too
lazy to craft a regression test using sufficiently backwards-compatible
library functions".
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
^ permalink raw reply [nested|flat] 28+ messages in thread
* Re: pgsql: Add transforms feature
2015-04-26 14:53 pgsql: Add transforms feature Peter Eisentraut <peter_e@gmx.net>
2015-04-26 16:36 ` Re: pgsql: Add transforms feature Tom Lane <tgl@sss.pgh.pa.us>
2015-05-02 14:58 ` Re: pgsql: Add transforms feature Peter Eisentraut <peter_e@gmx.net>
2015-05-03 21:03 ` Re: pgsql: Add transforms feature Tom Lane <tgl@sss.pgh.pa.us>
2015-05-03 21:37 ` Re: pgsql: Add transforms feature Tom Lane <tgl@sss.pgh.pa.us>
2015-05-03 22:27 ` Re: pgsql: Add transforms feature Tom Lane <tgl@sss.pgh.pa.us>
2015-05-03 22:49 ` Re: pgsql: Add transforms feature Andrew Dunstan <andrew@dunslane.net>
2015-05-03 22:54 ` Re: pgsql: Add transforms feature Tom Lane <tgl@sss.pgh.pa.us>
@ 2015-05-03 23:41 ` Andrew Dunstan <andrew@dunslane.net>
0 siblings, 0 replies; 28+ messages in thread
From: Andrew Dunstan @ 2015-05-03 23:41 UTC (permalink / raw)
To: Tom Lane <tgl@sss.pgh.pa.us>; +Cc: Peter Eisentraut <peter_e@gmx.net>; pgsql-committers
On 05/03/2015 06:54 PM, Tom Lane wrote:
> Andrew Dunstan <andrew@dunslane.net> writes:
>> On 05/03/2015 06:27 PM, Tom Lane wrote:
>>> Well, it sort of works. Looks like the hstore_plpython test is expecting
>>> some library function that Python 2.3 doesn't have.
>> I don't know if we have a standard for supported Python versions, but
>> Python 2.3.0 was released in 2003, and the last release in the series,
>> 2.3.7 was released in March 2008. Is that really what ships on a modern OSX?
> No, of course not; prairiedog is a very very trailing-edge box.
> However, we explicitly claim support for Python >= 2.3 in the docs (see
> installation.sgml), which is why prairiedog has that version and not
> some other one. If we're going to move the goalposts on the minimum
> supported version, it should be for a better reason than "I was too
> lazy to craft a regression test using sufficiently backwards-compatible
> library functions".
>
>
Oh, sorry, I misunderstood. As it's just a matter of a function call
from python by all means let's change it. The docs say "sorted" is new
in 2.4. See <https://docs.python.org/2/library/functions.html#sorted;,
but this will surely be fairly trivial to fix.
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
^ permalink raw reply [nested|flat] 28+ messages in thread
* Re: pgsql: Add transforms feature
2015-04-26 14:53 pgsql: Add transforms feature Peter Eisentraut <peter_e@gmx.net>
@ 2015-04-27 17:27 ` Alvaro Herrera <alvherre@2ndquadrant.com>
2015-04-28 04:05 ` Re: pgsql: Add transforms feature Tom Lane <tgl@sss.pgh.pa.us>
1 sibling, 1 reply; 28+ messages in thread
From: Alvaro Herrera @ 2015-04-27 17:27 UTC (permalink / raw)
To: Peter Eisentraut <peter_e@gmx.net>; +Cc: 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
^ permalink raw reply [nested|flat] 28+ messages in thread
* Re: pgsql: Add transforms feature
2015-04-26 14:53 pgsql: Add transforms feature Peter Eisentraut <peter_e@gmx.net>
2015-04-27 17:27 ` Re: pgsql: Add transforms feature Alvaro Herrera <alvherre@2ndquadrant.com>
@ 2015-04-28 04:05 ` Tom Lane <tgl@sss.pgh.pa.us>
0 siblings, 0 replies; 28+ messages in thread
From: Tom Lane @ 2015-04-28 04:05 UTC (permalink / raw)
To: Alvaro Herrera <alvherre@2ndquadrant.com>; +Cc: Peter Eisentraut <peter_e@gmx.net>; 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
^ permalink raw reply [nested|flat] 28+ messages in thread
end of thread, other threads:[~2015-05-08 15:27 UTC | newest]
Thread overview: 28+ messages (download: mbox mbox.gz follow: Atom feed)
-- links below jump to the message on this page --
2015-04-26 14:53 pgsql: Add transforms feature Peter Eisentraut <peter_e@gmx.net>
2015-04-26 16:36 ` Tom Lane <tgl@sss.pgh.pa.us>
2015-04-27 06:23 ` Michael Paquier <michael.paquier@gmail.com>
2015-04-27 12:21 ` Peter Eisentraut <peter_e@gmx.net>
2015-04-27 23:54 ` Andrew Dunstan <andrew@dunslane.net>
2015-04-28 00:55 ` Andrew Dunstan <andrew@dunslane.net>
2015-04-28 01:01 ` Michael Paquier <michael.paquier@gmail.com>
2015-04-28 13:04 ` Michael Paquier <michael.paquier@gmail.com>
2015-04-28 15:51 ` Andrew Dunstan <andrew@dunslane.net>
2015-04-28 16:03 ` Andrew Dunstan <andrew@dunslane.net>
2015-04-28 16:51 ` Andrew Dunstan <andrew@dunslane.net>
2015-04-28 20:10 ` Andrew Dunstan <andrew@dunslane.net>
2015-04-28 20:15 ` Peter Eisentraut <peter_e@gmx.net>
2015-04-29 04:47 ` Michael Paquier <michael.paquier@gmail.com>
2015-04-29 18:30 ` Andrew Dunstan <andrew@dunslane.net>
2015-04-29 21:55 ` Michael Paquier <michael.paquier@gmail.com>
2015-05-02 14:58 ` Peter Eisentraut <peter_e@gmx.net>
2015-05-03 18:27 ` Tom Lane <tgl@sss.pgh.pa.us>
2015-05-06 02:24 ` Peter Eisentraut <peter_e@gmx.net>
2015-05-08 15:27 ` Tom Lane <tgl@sss.pgh.pa.us>
2015-05-03 21:03 ` Tom Lane <tgl@sss.pgh.pa.us>
2015-05-03 21:37 ` Tom Lane <tgl@sss.pgh.pa.us>
2015-05-03 22:27 ` Tom Lane <tgl@sss.pgh.pa.us>
2015-05-03 22:49 ` Andrew Dunstan <andrew@dunslane.net>
2015-05-03 22:54 ` Tom Lane <tgl@sss.pgh.pa.us>
2015-05-03 23:41 ` Andrew Dunstan <andrew@dunslane.net>
2015-04-27 17:27 ` Alvaro Herrera <alvherre@2ndquadrant.com>
2015-04-28 04:05 ` Tom Lane <tgl@sss.pgh.pa.us>
This inbox is served by DDX for PostgreSQL; see mirroring instructions
for how to clone and mirror all data and code used for this inbox