Peter Eisentraut <pete...@gmx.net> writes: > On 4/28/15 12:05 AM, Tom Lane wrote: >> 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?
> The reason for the current setup is actually that when plperl and later > plpython was added, we still had Perl and Python client modules in our > tree (Pg.pm and pygresql), and configure --with-perl and --with-python > were meant to activate their build primarily. Also, in those days, > having a shared libperl or libpython was rare. But we didn't want to > fail the frontend interface builds because of that. So we arrived at > the current workaround. Ah. I'm glad you remember, because I didn't. > My preference would be to rip all that out and let the compiler or > linker decide when it doesn't want to link something. Works for me, assuming that we get an understandable failure message and not, say, a plperl.so that mysteriously doesn't work. 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