RE: trouble making PG use my Perl

From: Kevin Brannen <KBrannen(at)efji(dot)com>
To: "pgsql-general(at)lists(dot)postgresql(dot)org" <pgsql-general(at)lists(dot)postgresql(dot)org>
Subject: RE: trouble making PG use my Perl
Date: 2020-03-02 23:02:20
Message-ID: SN6PR19MB22721B39EAEF16FB2AB9AFE0A4E70@SN6PR19MB2272.namprd19.prod.outlook.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-general

From: Steven Lembark <lembark(at)wrkhors(dot)com>

>Funny thing is that both PG and Perl are easy enough to build from scratch and the centos compile of Perl at least is both ancient and horrid enough (5.00503 compatibility, really?) that it's easier to just shell-script both builds and run it overnight.

>Q: How un-optimized and ancient is the PG on centos?

I agree that it's not all that hard to compile my own Perl and Pg; I've done it in the past. That being said, I'd prefer to avoid it and now I can avoid compiling Pg.

On Centos 6.10, it ships with Perl 5.10.1, which is really ancient to me. Centos 8 ships with 5.14 (IIRC). Still pretty bad and it makes me like your conspiracy theory about Python folks ignoring it on purpose. 😊 They do compile with -O2 and MULTIPLICITY, so it's not too bad.

In the end, I found there were only 2 plperlu functions. Turns out 1 wasn't even used anymore (gotta love legacy code) and the other function was only called in 1 place, so it was moved into a module and adjusted (spi_* calls turned into DBI calls, etc). After that, there was no more reason for the plperlu extension so the problem no longer matters and I can load 1 less rpm.

I find it a shame we can't just swap Perl libraries, but I can understand why when I stop to really think about it.

Kevin
This e-mail transmission, and any documents, files or previous e-mail messages attached to it, may contain confidential information. If you are not the intended recipient, or a person responsible for delivering it to the intended recipient, you are hereby notified that any disclosure, distribution, review, copy or use of any of the information contained in or attached to this message is STRICTLY PROHIBITED. If you have received this transmission in error, please immediately notify us by reply e-mail, and destroy the original transmission and its attachments without reading them or saving them to disk. Thank you.

In response to

Responses

Browse pgsql-general by date

  From Date Subject
Next Message Vik Fearing 2020-03-02 23:13:24 Re: Not Null Constraint vs Query Planning
Previous Message Don Seiler 2020-03-02 23:02:09 Re: Not Null Constraint vs Query Planning