Re: PL/Perl compilation error
От | Tom Lane |
---|---|
Тема | Re: PL/Perl compilation error |
Дата | |
Msg-id | 6465.967937622@sss.pgh.pa.us обсуждение исходный текст |
Ответ на | Re: PL/Perl compilation error (Jan Wieck <janwieck@Yahoo.com>) |
Список | pgsql-general |
Jan Wieck <janwieck@Yahoo.com> writes: > [ why hasn't plperl been fixed yet? ] IMHO, the portability problems with plperl will need a Perl guru to fix. Specifically somebody who knows the ins and outs of embedding Perl into other applications, which is not such a commonly done thing. pltcl was a simpler project because Tcl has always been designed to be embedded as a library into other applications. Perl is still in process of being redesigned from a standalone program into an embeddable library, and most everyday Perl programmers don't know much about the pitfalls that still remain in using it that way. Just to give you one example of the ways in which Perl is not designed to be embeddable: last I checked, libperl was not built as PIC code by default. On machines where that makes a difference (like HPUX) that means that plperl cannot work with a default Perl installation. Period. Not one damn thing you can do about it except reconfigure/rebuild/ reinstall Perl, which is a tad outside the charter of our build process. The cross-version compatibility issues could be fixed more easily, but probably not with just an hour or two's work (has anyone here actually done anything with Devel::PPPort? how hard is it?). When working around them just takes "add POLLUTE=1 to Makefile build", I can see why people aren't eager to invest the work for a cleaner solution. Perl is getting better over time (indeed 5.6.0 may do the right thing already on the PIC front; I haven't installed it yet) but I think in the near term it's going to be difficult to have a really robust portability solution for plperl. regards, tom lane
В списке pgsql-general по дате отправления: