Re: [COMMITTERS] pgsql: Add transforms feature - Mailing list pgsql-hackers

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