Re: [COMMITTERS] pgsql: Add transforms feature - Mailing list pgsql-hackers
| From | Andrew Dunstan |
|---|---|
| Subject | Re: [COMMITTERS] pgsql: Add transforms feature |
| Date | |
| Msg-id | 553FE942.4040604@dunslane.net Whole thread Raw |
| Responses |
Re: [COMMITTERS] pgsql: Add transforms feature
Re: [COMMITTERS] pgsql: Add transforms feature |
| List | pgsql-hackers |
On 04/28/2015 12:03 PM, Andrew Dunstan wrote:
>
> [switching to -hackers]
>
> On 04/28/2015 11:51 AM, Andrew Dunstan wrote:
>>
>> On 04/28/2015 09:04 AM, Michael Paquier wrote:
>>> On Tue, Apr 28, 2015 at 10:01 AM, Michael Paquier
>>> <michael.paquier@gmail.com> wrote:
>>>> On Tue, Apr 28, 2015 at 9:55 AM, Andrew Dunstan wrote:
>>>>> w.r.t MSVC builds, it looks like we need entries in
>>>>> $contrib_extraincludes
>>>>> in src/tools/msvc/Mkvcbuild.pm at the very least.
>>>> If our goal is to put back to green the Windows nodes as quick as
>>>> possible, we could bypass their build this way , and we'll
>>>> additionally need to update the install script and
>>>> vcregress.pl/contribcheck to bypass those modules accordingly. Now I
>>>> don't think that we should make the things produced inconsistent.
>>> OK, attached are two patches to put back the buildfarm nodes using
>>> MSVC to green
>>> - 0001 adds support for build and installation of the new transform
>>> modules: hstore_plperl, hstore_plpython and ltree_plpython. Note that
>>> this patch is enough to put back the buildfarm to a green state for
>>> MSVC, but it disables the regression tests for those modules,
>>> something addressed in the next patch...
>>> - 0002 adds support for regression tests for the new modules. The
>>> thing is that we need to check the major version version of Python
>>> available in configuration and choose what are the extensions to
>>> preload before the tests run. It is a little bit hacky... But it has
>>> the merit to work, and I am not sure we could have a cleaner solution
>>> by looking at the Makefiles of the transform modules that use
>>> currently conditions based on $(python_majorversion).
>>> Regards,
>>
>>
>> I have pushed the first of these with some tweaks.
>>
>> I'm looking at the second.
>>
>>
>
>
> Regarding this second patch - apart from the buggy python version test
> which I just fixed in the first patch, I see this:
>
> + if ($pyver eq "2")
> + {
> + push @opts, "--load-extension=plpythonu";
> + push @opts, '--load-extension=' . $module . 'u';
> + }
>
>
> But what do we do for Python3?
>
> Do we actually have a Windows machine building with Python3?
The answer seems to be "probably not". When I tried enabling this with
bowerbird I got a ton of errors like these:
plpy_cursorobject.obj : error LNK2001: unresolved external symbol PyObject_SelfIter
[C:\prog\bf\root\HEAD\pgsql\plpython3.vcxproj] plpy_cursorobject.obj : error LNK2019: unresolved external symbol
__imp_PyType_Readyreferenced in function PLy_cursor_init_type [C:\prog\bf\root\HEAD\pgsql\plpython3.vcxproj]
Something else to fix I guess.
cheers
andrew
pgsql-hackers by date: