ImportError: 'plpy' is not a built-in module

[df7cb]

Hi,

I'm getting regression failures in write_filesystem when trying to build multicorn on Debian unstable with PG 9.5:

15:59:31 --- 38,396 ----
15:59:31                   with open(os.path.join(dirname, '.'.join([name, ext])), 'a') as fd:
15:59:31                       fd.write('Im a %s %s %s\n' % (size, color, name))
15:59:31   $$ language plpython3u;
15:59:31 + ERROR:  could not import "__main__" module
15:59:31 + DETAIL:  ImportError: 'plpy' is not a built-in module
15:59:31   select create_table();
15:59:31 ! ERROR:  function create_table() does not exist
15:59:31 ! LINE 1: select create_table();
15:59:31 !                ^
15:59:31 ! HINT:  No function matches the given name and argument types. You might need to add explicit type casts.
15:59:31   -- End of Setup

TBH I have no clue what the error means, is that something I need to fix in the package/build system, or is something wrong in multicorn?

[rdunklau]

It seems like with Python3 and recent versions of Postgres, the initialization has changed.

The following works:

CREATE EXTENSION plpython3u; CREATE FUNCTION LANGUAGE plpython3u; CREATE EXTENSION MULTICORN;

The following doesn't: CREATE EXTENSION MULTICORN; CREATE EXTENSION plpython3u; CREATE FUNCTION LANGUAGE plpython3u;

For some reason, the second form doesn't initialize plpy as a built in module, probably because the interpreter was initialized by Multicorn and not by plpy.

I have quite an ugly workaround: if on python3, call a function that will check if plpython3 exists, and in that case, force it to load.

There probably were problems before between plpython and Multicorn, so I'm not sure if building this workaround in Multicorn is the best thing, or if it should be manually implemented by the users (making sure that plpython is used BEFORE Multicorn if both of them are going to be used).

[rdunklau]

The fix is here: https://github.com/Kozea/Multicorn/commit/485c5c6c0dae58b5c6dd093809d83f09fc56f8d4

[df7cb]

I confirm that this (admittedly ugly) patch fixes the problem. Thanks!

[fladi]

I think this broke refreshing materialized views for me because "plpython3u" is not a trusted language and only superusers are allowed to run anonymous block in such languages.

[fladi]

It seems that when I try to refresh a materialized view that is backed by a foreign (multicorn) table the multicorn_check_plpython3u function ist called in the context of the owner of the materialized view, which in my case is the application user without superuser privileges.

[rdunklau]

Fixed on master.