I still got the binaries of the installation and I found that I have the next directory :
postgresql-10.4/src/pl/
cd
postgresql-10.4/src/pl/plpython
-rw-r--r-- 1 postgres postgres 653 May 7 23:51 Makefile
drwxr-xr-x 3 postgres postgres 33 May 8 00:03 plpgsql
drwxr-xr-x 5 postgres postgres 4096 May 8 00:03 plperl
drwxr-xr-x 5 postgres postgres 319 May 8 00:06 tcl
drwxr-xr-x 5 postgres postgres 4096 May 8 00:06 plpython
is there a way to install the extension from here ?
2018-07-08 17:18 GMT+03:00 Justin Pryzby <pryzby@xxxxxxxxxxxxx>:
On Sun, Jul 08, 2018 at 04:46:47PM +0300, Mariel Cherkassky wrote:
> As I mentioned earlier, I already have a running postgresql instance on the
> machibe but on different pathes. I didnt want to install another one with
> the default pathes because I didnt want people to think that the default
> pathes are the correct ones. If I'll install the package to the default
> values then the solution is just coppying the plpythonu.control to my
> instance`s extensions directory ?
I'm not sure about compatibilty of differently compiled binaries (different
--configure flags, different compiler/version, different PG minor versions),
but I think that could work..
As I mentioned, you could also EXTRACT the PGDG postgresql10-plpython files
without installing the -server.
Or you could compile+install the plpython extension. I'm not sure but I think
that would be ./configure --with-python.
..However if it were me, I'd schedule a time to stop the server, move the
custom-compiled binaries out of the way, and restart using the PGDG binaries
pointing at the original data dir. I think the only condition for doing this
is keep the same major version (10) and to avoid lower minor versions (eg. once
you start with PGDG 10.4 binaries you should avoid going back and starting with
locally-compiled 10.3 binaries).
Justin
