PL/Perl compilation error

Alex Guryanow <gav@nlr.ru> writes:

[root@eaccess plperl]# perl Makefile.PL

For recent Perl versions you need to do
perl Makefile.PL POLLUTE=1
instead. The src/pl Makefile would've done it that way for you,
but it looks like that code patch didn't make it to the docs...

Someone needs to update our Perl code so that it will compile cleanly
against both newer and not-so-new Perls. There are notes in our mail
archives about how to do this (basically "use Devel::PPPort" is the
long-term answer) but it hasn't gotten to the top of anyone's to-do
list.

regards, tom lane

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

Tom Lane wrote:

Alex Guryanow <gav@nlr.ru> writes:

[root@eaccess plperl]# perl Makefile.PL

For recent Perl versions you need to do
perl Makefile.PL POLLUTE=1
instead. The src/pl Makefile would've done it that way for you,
but it looks like that code patch didn't make it to the docs...

Someone needs to update our Perl code so that it will compile cleanly
against both newer and not-so-new Perls. There are notes in our mail
archives about how to do this (basically "use Devel::PPPort" is the
long-term answer) but it hasn't gotten to the top of anyone's to-do
list.

Can someone eventually enlighten me a little?

We've had problems like platform/version dependant
compilation errors with PL/Tcl in the past too, but they got
fixed pretty quick and a reasonable number of people worked
on that all together.

We have frequent compilation error reports with PL/perl but
nobody seems to be able/willing to do anything about it.

PL/perl was once highly requested feature. Now there is a
code base and lesser experienced programmers could continue
the work, but nobody does.

What is the problem with perl? Are there only alot of users
but no hackers? The frequent fail reports suggest that there
are folks who want to have that thing running. I can't
believe that a piece of open source software, that is so
popular, is implemented in such an ugly way that nobody has a
clue how to fix that damned thing.

So please tell me why people spend their time writing error
reports again and again instead of simply fixing it and
submitting a patch.

Jan

--

#======================================================================#
# It's easier to get forgiveness for being wrong than for being right. #
# Let's break this rule - forgive me. #
#================================================== JanWieck@Yahoo.com #

Hi,

I have take a look to the source code concerning PL/Perl, it seems that 2 variables
have a bad call : errgv and na.

If you replace them by their normal call (in 5.6.0) PL_errgv and PL_na you will get
success to compile the lib plperl.so.

Also in Perl documentation you will find the answer for backward compatibility :

The API function perl_get_sv("@",FALSE) should be used instead of directly accessing
perl globals as GvSV(errgv). The API call is backward compatible with existing perls and
provides source compatibility with threading is enabled.

It seems to be easily repared. I have no time yet but I will take a look as soon as possible.

Regards
Gilles

Alex Guryanow wrote:

Show quoted text

Hi,

I have just installed Perl 5.6.0 and PostgreSQL 7.0.2. After successfull installation of both these
programs I tried to make PL/Perl support. After running the commands from Postgres manual I have
received the following errors

This week, I had the opportunity to compare the performance of PostgreSQL
on an Alpha and an Intel server, and the results kind of surprised me. I'd
love to hear if this has been the case for others as well...

-------------
Intel Machine

SuperMicro 8050 quad Xeon server
512 MB RAM
4 x PII Xeon 400 MHz (secondary cache disabled)
RAID array w/ 5 9-gig drives

Approximate cost: $6000
--------------
Alpha Machine
AlphaServer DS20E
2 x CPU (500 MHz or 667 MHz)
2 GB RAM
9-gig SCSI drive

Approximate cost: $20,000 - $25,000
-----------------------

General System notes

I'm not sure which chips the Alpha uses, the 500 MHz or the 667 MHz.
Also, because the SuperMicro board is meant for the newer Xeons, the
secondary cache had to be completely disabled on the PII 400 Xeons, so that
machine was definitely not running up to potential.

-------------------------
Test method

This wasn't exactly the ANSI tests, but it accurately reflected what we
need out of a machine. A while back we logged 87,000 individual queries on
our production machine, and I selected one thousand distinct queries from
that.

On each machine I spawned 20 parallel processes, each performing the
1,000 queries, and timed how long it took for all processes to finish.

To try and keep the disk subsystem from being a factor, this used only
selects, no updates or deletes. Also, the database is small enough that the
entire thing was easily in the disk cache at all times.
--------------------------
Test results

The Alpha finished in just over 60 minutes, the Xeon finished in just over
90.

-----------------------------
Test interpretation

Once I started looking at the numbers, I was suprised. On a
processor-for-processor basis, the Alpha was three times as fast as the
Intels. However, the Intels that it was pitted against were only 400 MHz
chips, only PII (not the PIII), *and* had the external cache completely
disabled.

So, the Alpha provided three times the performance for four times the
cost - but if the megabyte of cache had been enabled on the Xeons, I think
that the results would have been significantly different. Also, if the
chips had been even relatively recent chips (say, some 700 or 800 MHz Xeons)
with the cache enabled, it's possible that it could have come close to the
performance of the Alpha, at a much lower cost.

Overall, I was expecting the Alpha to give the Intel a better trouncing,
especially considering the difference in cost, but I guess it's hard to beat
Intel for transactions/dollar. If sheer server capacity is the only
relevant factor, forget Intel (You won't find Intels with 64 processors, and
I don't think you'll see them even with the Itaniums). If your needs are
more down-to-Earth, they're the best you can get for the money.

steve

I'm curious, what OS did you perform these test under?

-Mitch

----- Original Message -----
From: "Steve Wolfe" <steve@iboats.com>
To: <pgsql-general@postgresql.org>
Sent: Tuesday, September 05, 2000 10:14 AM
Subject: [GENERAL] Report of performance on Alpha vs. Intel

This week, I had the opportunity to compare the performance of

PostgreSQL

on an Alpha and an Intel server, and the results kind of surprised me.

I'd

love to hear if this has been the case for others as well...

-------------
Intel Machine

SuperMicro 8050 quad Xeon server
512 MB RAM
4 x PII Xeon 400 MHz (secondary cache disabled)
RAID array w/ 5 9-gig drives

Approximate cost: $6000
--------------
Alpha Machine
AlphaServer DS20E
2 x CPU (500 MHz or 667 MHz)
2 GB RAM
9-gig SCSI drive

Approximate cost: $20,000 - $25,000
-----------------------

General System notes

I'm not sure which chips the Alpha uses, the 500 MHz or the 667 MHz.
Also, because the SuperMicro board is meant for the newer Xeons, the
secondary cache had to be completely disabled on the PII 400 Xeons, so

that

machine was definitely not running up to potential.

-------------------------
Test method

This wasn't exactly the ANSI tests, but it accurately reflected what we
need out of a machine. A while back we logged 87,000 individual queries

on

our production machine, and I selected one thousand distinct queries from
that.

On each machine I spawned 20 parallel processes, each performing the
1,000 queries, and timed how long it took for all processes to finish.

To try and keep the disk subsystem from being a factor, this used only
selects, no updates or deletes. Also, the database is small enough that

the

entire thing was easily in the disk cache at all times.
--------------------------
Test results

The Alpha finished in just over 60 minutes, the Xeon finished in just

over

90.

-----------------------------
Test interpretation

Once I started looking at the numbers, I was suprised. On a
processor-for-processor basis, the Alpha was three times as fast as the
Intels. However, the Intels that it was pitted against were only 400 MHz
chips, only PII (not the PIII), *and* had the external cache completely
disabled.

So, the Alpha provided three times the performance for four times the
cost - but if the megabyte of cache had been enabled on the Xeons, I think
that the results would have been significantly different. Also, if the
chips had been even relatively recent chips (say, some 700 or 800 MHz

Xeons)

with the cache enabled, it's possible that it could have come close to the
performance of the Alpha, at a much lower cost.

Overall, I was expecting the Alpha to give the Intel a better trouncing,
especially considering the difference in cost, but I guess it's hard to

beat

Intel for transactions/dollar. If sheer server capacity is the only
relevant factor, forget Intel (You won't find Intels with 64 processors,

and

Show quoted text

I don't think you'll see them even with the Itaniums). If your needs are
more down-to-Earth, they're the best you can get for the money.

steve

I'm curious, what OS did you perform these test under?

Doh! Silly me.

The Xeon ran a Linux 2.2.16 kernel, and the Alpha ran "Tru64".

Steve

Memory and cache are the most important parameters for db server, and PC
lacks both.

At 19:14 5.9.2000 , Steve Wolfe wrote:

This week, I had the opportunity to compare the performance of PostgreSQL
on an Alpha and an Intel server, and the results kind of surprised me. I'd
love to hear if this has been the case for others as well...

-------------
Intel Machine

SuperMicro 8050 quad Xeon server
512 MB RAM
4 x PII Xeon 400 MHz (secondary cache disabled)
RAID array w/ 5 9-gig drives

Approximate cost: $6000
--------------
Alpha Machine
AlphaServer DS20E
2 x CPU (500 MHz or 667 MHz)
2 GB RAM
9-gig SCSI drive

Approximate cost: $20,000 - $25,000
-----------------------

General System notes

I'm not sure which chips the Alpha uses, the 500 MHz or the 667 MHz.
Also, because the SuperMicro board is meant for the newer Xeons, the
secondary cache had to be completely disabled on the PII 400 Xeons, so that
machine was definitely not running up to potential.

-------------------------
Test method

This wasn't exactly the ANSI tests, but it accurately reflected what we
need out of a machine. A while back we logged 87,000 individual queries on
our production machine, and I selected one thousand distinct queries from
that.

On each machine I spawned 20 parallel processes, each performing the
1,000 queries, and timed how long it took for all processes to finish.

To try and keep the disk subsystem from being a factor, this used only
selects, no updates or deletes. Also, the database is small enough that the
entire thing was easily in the disk cache at all times.
--------------------------
Test results

The Alpha finished in just over 60 minutes, the Xeon finished in just over
90.

-----------------------------
Test interpretation

Once I started looking at the numbers, I was suprised. On a
processor-for-processor basis, the Alpha was three times as fast as the
Intels. However, the Intels that it was pitted against were only 400 MHz
chips, only PII (not the PIII), *and* had the external cache completely
disabled.

So, the Alpha provided three times the performance for four times the
cost - but if the megabyte of cache had been enabled on the Xeons, I think
that the results would have been significantly different. Also, if the
chips had been even relatively recent chips (say, some 700 or 800 MHz Xeons)
with the cache enabled, it's possible that it could have come close to the
performance of the Alpha, at a much lower cost.

Overall, I was expecting the Alpha to give the Intel a better trouncing,
especially considering the difference in cost, but I guess it's hard to beat
Intel for transactions/dollar. If sheer server capacity is the only
relevant factor, forget Intel (You won't find Intels with 64 processors, and
I don't think you'll see them even with the Itaniums). If your needs are
more down-to-Earth, they're the best you can get for the money.

steve

v
Zeljko Trogrlic
____________________________________________________________

Aeris d.o.o.
Sv. Petka 60 b, HR-31000 Osijek, Croatia
Tel: +385 (31) 53 00 15
Email: mailto:zeljko@post.hinet.hr

Can you send me a patch?

Hi,

I have take a look to the source code concerning PL/Perl, it seems that 2 variables
have a bad call : errgv and na.

If you replace them by their normal call (in 5.6.0) PL_errgv and PL_na you will get
success to compile the lib plperl.so.

Also in Perl documentation you will find the answer for backward compatibility :

The API function perl_get_sv("@",FALSE) should be used instead of directly accessing
perl globals as GvSV(errgv). The API call is backward compatible with existing perls and
provides source compatibility with threading is enabled.

It seems to be easily repared. I have no time yet but I will take a look as soon as possible.

Regards
Gilles

Alex Guryanow wrote:

Hi,

I have just installed Perl 5.6.0 and PostgreSQL 7.0.2. After successfull installation of both these
programs I tried to make PL/Perl support. After running the commands from Postgres manual I have
received the following errors

-- 
  Bruce Momjian                        |  http://candle.pha.pa.us
  pgman@candle.pha.pa.us               |  (610) 853-3000
  +  If your life is a hard drive,     |  830 Blythe Avenue
  +  Christ can be your backup.        |  Drexel Hill, Pennsylvania 19026

Bruce Momjian wrote:

Can you send me a patch?

Hi,

I have take a look to the source code concerning PL/Perl, it seems that 2 variables
have a bad call : errgv and na.

If you replace them by their normal call (in 5.6.0) PL_errgv and PL_na you will get
success to compile the lib plperl.so.

This patch (simple diff) applies to postgresql-7.0.2.
See attachment...

Regards

Gilles DAROLD

I can not apply this. Seems it has changed in the current tree. Here
is the current plperl.c file.

Bruce Momjian wrote:

Can you send me a patch?

Hi,

I have take a look to the source code concerning PL/Perl, it seems that 2 variables
have a bad call : errgv and na.

If you replace them by their normal call (in 5.6.0) PL_errgv and PL_na you will get
success to compile the lib plperl.so.

This patch (simple diff) applies to postgresql-7.0.2.
See attachment...

Regards

Gilles DAROLD

328c328
< if (SvTRUE(GvSV(PL_errgv)))
---

if (SvTRUE(GvSV(errgv)))

334c334
< elog(ERROR, "creation of function failed : %s", SvPV(GvSV(PL_errgv), PL_na));
---

elog(ERROR, "creation of function failed : %s", SvPV(GvSV(errgv), na));

444c444
< if (SvTRUE(GvSV(PL_errgv)))
---

if (SvTRUE(GvSV(errgv)))

450c450
< elog(ERROR, "plperl : error from function : %s", SvPV(GvSV(PL_errgv), PL_na));
---

elog(ERROR, "plperl : error from function : %s", SvPV(GvSV(errgv), na));

654c654
< (SvPV(perlret, PL_na),
---

(SvPV(perlret, na),

2192c2192
< output = perl_eval_pv(SvPV(output, PL_na), TRUE);
---

output = perl_eval_pv(SvPV(output, na), TRUE);

-- 
  Bruce Momjian                        |  http://candle.pha.pa.us
  pgman@candle.pha.pa.us               |  (610) 853-3000
  +  If your life is a hard drive,     |  830 Blythe Avenue
  +  Christ can be your backup.        |  Drexel Hill, Pennsylvania 19026

Gilles DAROLD <gilles@darold.net> writes:

I have take a look to the source code concerning PL/Perl, it seems that 2 variables
have a bad call : errgv and na.

If you replace them by their normal call (in 5.6.0) PL_errgv and PL_na you will get
success to compile the lib plperl.so.

This patch (simple diff) applies to postgresql-7.0.2.

The problem is this will break on older copies of Perl.

regards, tom lane

Tom Lane wrote:

Gilles DAROLD <gilles@darold.net> writes:

I have take a look to the source code concerning PL/Perl, it seems that 2 variables
have a bad call : errgv and na.

If you replace them by their normal call (in 5.6.0) PL_errgv and PL_na you will get
success to compile the lib plperl.so.

This patch (simple diff) applies to postgresql-7.0.2.

The problem is this will break on older copies of Perl.

regards, tom lane

This problem is solved by perl itself !

I know it work under perl > 5.005_3 and certainly all versions after perl 5.004.
Give me a reason to keep buggy perl versions compatibility ! People still
running version prior of 5.005_3 does not really want perl running well so
why plperl :-)

If you are not agree with my last comment, just take a look to the change log
of the perl version history and you will understand what I mean (security, memory,
etc.) ...

Regards

Gilles DAROLD

Bruce Momjian wrote:

I can not apply this. Seems it has changed in the current tree. Here
is the current plperl.c file.

It seems that the current file has been fixed. There's no more call to the
buggy variables in it. I don't know what you want me to do ?
Do you still have problem to compiling this code ? If so send me an url
where i can find the complete PG distribution you want to see working.
I will check if it works for me and try to fix if there is problems.
Not sure of what I can do...

Regards

Gilles DAROLD

hello.

i have the following trigger:

CREATE TRIGGER trig_person_accessorclass BEFORE INSERT ON Person FOR EACH
ROW EXECUTE PROCEDURE sp_person_accessorclass();

the corresponding function inserts a row into the accessor_class table.

the issue is that when i insert a row into person and immediately query the
accessor_class table, i don't find anything. does it take some amount of
time for the trigger/sp to run? is it just placed in a queue or something?
can i speed this up or is it best to not count on the performance of the
function?

thanks

chris

Gilles DAROLD <gilles@darold.net> writes:

The problem is this will break on older copies of Perl.

This problem is solved by perl itself !

Yeah, it is: there is a module called Devel::PPPort that isolates
user C code from the incompatibilities of different Perl APIs. Until
someone gets around to submitting a proper fix using PPPort, we'll stick
with the POLLUTE=1 solution we have now. I see no reason to install an
incomplete solution that will fail on older Perls --- we are not in the
business of forcing people to update their Perls.

I was going to point you to the pgsql-bugs archive for 3/25/00, but
there seems to be a gap in the archive in March, so attached are the
relevant messages.

regards, tom lane

------- Forwarded Messages

Date: Sat, 25 Mar 2000 13:15:28 +0100
From: Marc Lehmann <pcg@goof.com>
To: pgsql-bugs@postgresql.org
Subject: [BUGS] perl5 interface won't compile

============================================================================
POSTGRESQL BUG REPORT TEMPLATE
============================================================================

Your name : Marc Lehmann
Your email address : pcg@goof.com

System Configuration
---------------------
Architecture (example: Intel Pentium) :

Operating System (example: Linux 2.0.26 ELF) :

PostgreSQL version (example: PostgreSQL-6.5.1): PostgreSQL-7.0beta3

Compiler used (example: gcc 2.8.0) :

Please enter a FULL description of your problem:
------------------------------------------------

the perl interface does not compile with newer perl versions (5.006 and
probably 5.005 without options).

Please describe a way to repeat the problem. Please try to provide a

(sorry, just found out that plperl also won't compile, so I have "re-added"
another, a second diff against plperl ;)

concise reproducible example, if at all possible:
----------------------------------------------------------------------

"make"

If you know how this problem might be fixed, list the solution below:
---------------------------------------------------------------------

A diff against Pg.xs is attached, however, it will not compile with older
perl versions (it is the prefered long-term solution).

So, for the forseeable future, it might be a better to create the Makefile
using

perl Makefile.PL POLLUTE=1

which will enable some kind of compatibility mode.

A preferable but better solution would be to use the Devel::PPPort module
(on CPAN) to get rid of versiondependonitis (in which case you will need
to apply both diffs and additionally include ppport.h, preferably after
renaming it to something else.

===PATCH 1===================================================================

diff -r -u perl5o/Pg.c perl5/Pg.c
--- perl5o/Pg.c	Sat Mar 25 13:09:05 2000
+++ perl5/Pg.c	Sat Mar 25 13:10:38 2000
@@ -1407,7 +1407,7 @@
 		ps.caption   = caption;
 		Newz(0, ps.fieldName, items + 1 - 11, char*);
 		for (i = 11; i < items; i++) {
-			ps.fieldName[i - 11] = (char *)SvPV(ST(i), na);
+			ps.fieldName[i - 11] = (char *)SvPV_nolen(ST(i));
 		}
 		PQprint(fout, res, &ps);
 		Safefree(ps.fieldName);
@@ -3182,7 +3182,7 @@
 				EXTEND(sp, cols);
 				while (col < cols) {
 					if (PQgetisnull(res->result, res->row, col)) {
-						PUSHs(&sv_undef);
+						PUSHs(&PL_sv_undef);
 					} else {
 						char *val = PQgetvalue(res->result, res->row, col);
 						PUSHs(sv_2mortal((SV*)newSVpv(val, 0)));
@@ -3238,7 +3238,7 @@
 		ps.caption   = caption;
 		Newz(0, ps.fieldName, items + 1 - 11, char*);
 		for (i = 11; i < items; i++) {
-			ps.fieldName[i - 11] = (char *)SvPV(ST(i), na);
+			ps.fieldName[i - 11] = (char *)SvPV_nolen(ST(i));
 		}
 		PQprint(fout, res->result, &ps);
 		Safefree(ps.fieldName);
diff -r -u perl5o/Pg.xs perl5/Pg.xs
--- perl5o/Pg.xs	Sat Mar 11 04:08:37 2000
+++ perl5/Pg.xs	Sat Mar 25 13:10:36 2000
@@ -581,7 +581,7 @@
 		ps.caption   = caption;
 		Newz(0, ps.fieldName, items + 1 - 11, char*);
 		for (i = 11; i < items; i++) {
-			ps.fieldName[i - 11] = (char *)SvPV(ST(i), na);
+			ps.fieldName[i - 11] = (char *)SvPV_nolen(ST(i));
 		}
 		PQprint(fout, res, &ps);
 		Safefree(ps.fieldName);
@@ -1252,7 +1252,7 @@
 				EXTEND(sp, cols);
 				while (col < cols) {
 					if (PQgetisnull(res->result, res->row, col)) {
-						PUSHs(&sv_undef);
+						PUSHs(&PL_sv_undef);
 					} else {
 						char *val = PQgetvalue(res->result, res->row, col);
 						PUSHs(sv_2mortal((SV*)newSVpv(val, 0)));
@@ -1292,7 +1292,7 @@
 		ps.caption   = caption;
 		Newz(0, ps.fieldName, items + 1 - 11, char*);
 		for (i = 11; i < items; i++) {
-			ps.fieldName[i - 11] = (char *)SvPV(ST(i), na);
+			ps.fieldName[i - 11] = (char *)SvPV_nolen(ST(i));
 		}
 		PQprint(fout, res->result, &ps);
 		Safefree(ps.fieldName);

===PATCH 2===================================================================

diff -u -r plperlo/plperl.c plperl/plperl.c
--- plperlo/plperl.c	Sat Mar 25 13:17:31 2000
+++ plperl/plperl.c	Sat Mar 25 13:18:32 2000
@@ -309,12 +309,12 @@
 	perl_eval_sv(s, G_SCALAR | G_EVAL | G_KEEPERR);
 	SPAGAIN;

-	if (SvTRUE(GvSV(errgv))) {
+	if (SvTRUE(GvSV(PL_errgv))) {
 		POPs;
 		PUTBACK;
 		FREETMPS;
 		LEAVE;
-		elog(ERROR, "creation of function failed : %s", SvPV(GvSV(errgv), na));
+		elog(ERROR, "creation of function failed : %s", SvPV_nolen(GvSV(PL_errgv)));
 	}

/*
@@ -413,12 +413,12 @@
elog(ERROR, "plperl : didn't get a return item from function");
}

-	if (SvTRUE(GvSV(errgv))) {
+	if (SvTRUE(GvSV(PL_errgv))) {
 		POPs;
 		PUTBACK ;
 		FREETMPS ;
 		LEAVE;
-		elog(ERROR, "plperl : error from function : %s", SvPV(GvSV(errgv), na));
+		elog(ERROR, "plperl : error from function : %s", SvPV_nolen(GvSV(PL_errgv)));
 	}

retval = newSVsv(POPs);
@@ -632,7 +632,7 @@
elog(ERROR, "plperl: SPI_finish() failed");

retval = (Datum) (*fmgr_faddr(&prodesc->result_in_func))
- (SvPV(perlret, na),
+ (SvPV_nolen(perlret),
prodesc->result_in_elem,
prodesc->result_in_len);

@@ -2168,6 +2168,6 @@
 		}
 	}
 	sv_catpv(output, "}");
-	output = perl_eval_pv(SvPV(output, na), TRUE);
+	output = perl_eval_pv(SvPV_nolen(output), TRUE);
 	return output;
 }

=============================================================================

--
-----==- |
----==-- _ |
---==---(_)__ __ ____ __ Marc Lehmann +--
--==---/ / _ \/ // /\ \/ / pcg@opengroup.org |e|
-=====/_/_//_/\_,_/ /_/\_\ XX11-RIPE --+
The choice of a GNU generation |
|

------- Message 2

Date: Sat, 25 Mar 2000 11:49:09 -0500
From: Tom Lane <tgl@sss.pgh.pa.us>
To: Marc Lehmann <pcg@goof.com>
cc: pgsql-bugs@postgresql.org, pgsql-hackers@postgreSQL.org
Subject: Re: [BUGS] perl5 interface won't compile

Marc Lehmann <pcg@goof.com> writes:

the perl interface does not compile with newer perl versions (5.006 and
probably 5.005 without options).

We've seen this reported a few times, but in fact the perl code *does*
compile against 5.005_03 --- without options --- and AFAICT that is
still considered the current stable release of Perl. I'm pretty
hesitant to break backwards compatibility with pre-5.005 versions
just yet.

However, you are the first complainant who has suggested approaches
other than a non-backward-compatible source patch, so I'm all ears.

So, for the forseeable future, it might be a better to create the Makefile
using
perl Makefile.PL POLLUTE=1
which will enable some kind of compatibility mode.

Interesting. I could not find anything about POLLUTE at www.perl.com.
What does it do, and will it cause problems on pre-5.005 perls?

A preferable but better solution would be to use the Devel::PPPort module
(on CPAN) to get rid of versiondependonitis (in which case you will need
to apply both diffs and additionally include ppport.h, preferably after
renaming it to something else.

This looks like it could be the Right Thing To Do. Anyone have time to
make it happen (and perhaps even access to a few different perl versions
to test it)?

regards, tom lane

------- Message 3

Date: Sat, 25 Mar 2000 15:27:17 -0500
From: Tom Lane <tgl@sss.pgh.pa.us>
To: Bruce Momjian <pgman@candle.pha.pa.us>, Marc Lehmann <pcg@goof.com>,
pgsql-bugs@postgresql.org
Subject: Re: [BUGS] perl5 interface won't compile

I said

Bruce Momjian <pgman@candle.pha.pa.us> writes:

I have added your POLLUTE=1 solution to interfaces/perl5 and
plperl. Please try tomorrow's snapshot to see if this works for you.

I think the more interesting question is whether that breaks older
Perls...

I have now tried it with perl 5.004_04 (which was current about two
years ago), and I get

$ make plperl/Makefile
cd plperl && perl Makefile.PL POLLUTE=1
'POLLUTE' is not a known MakeMaker parameter name.
Writing Makefile for plperl

after which it seems to be happy. Assuming this fixes the problem
for bleeding-edge perls, this looks like a good stopgap answer until
someone feels like doing something with Devel::PPPort.

regards, tom lane

------- End of Forwarded Messages

On Tue, 17 Oct 2000, Tom Lane wrote:

Gilles DAROLD <gilles@darold.net> writes:

The problem is this will break on older copies of Perl.

This problem is solved by perl itself !

Yeah, it is: there is a module called Devel::PPPort that isolates
user C code from the incompatibilities of different Perl APIs. Until
someone gets around to submitting a proper fix using PPPort, we'll stick
with the POLLUTE=1 solution we have now. I see no reason to install an
incomplete solution that will fail on older Perls --- we are not in the
business of forcing people to update their Perls.

I believe that POLLUTE should be a default. People who are using perl5.004
are definitely a minority now. 5.004 is 3 years old now...

-alex

Alex Pilosov <alex@pilosoft.com> writes:

I believe that POLLUTE should be a default.

It is --- the src/pl and src/interfaces Makefiles will create the
sub-makefiles with POLLUTE=1. Unfortunately it's easy to miss that
fine point when you're building the Perl modules by hand. Not sure
if there's a good way to remind people about it.

regards, tom lane

Hi,

I have done a little work concerning the famous PL/Perl compilation Error and
also into Interfaces/Perl5.

The confusing POLLUTE option is no more used to see these parts compiled.
I thinks it's now fully compatible with all Perl versions, yes Tom I use PPPort :-)

The way to put it into the distribution package is very simple.

1) Replace the current GNUmakefile in these directories src/interface/perl5 and src/pl/plperl

by those given in the attachment.
2) Copy the lastest version of the ppport.h file into the same directories (latest can be
found
on CPAN) I provide one in the attachment (the latest at this day Version 1.0007)

That done, just compile postgresql exactly as before (with ./configure --with-perl at least).

What I have done is very simple :

- cp Devel-PPPort-1.0007/ppport.h postgresql-snapshotsrc/pl/plperl/
- cp Devel-PPPort-1.0007/ppport.h postgresql-snapshot/src/interfaces/perl5/

And in the 2 GNUmakefile in the "Makefile: Makefile.PL" section:

- I have remove the call to the POLLUTE option
- Added the following lines at the begining of the section:
$(PERL) -x ppport.h *.c *.h *.xs > ppport.patch
patch < ppport.patch
rm ppport.patch

Thanks to Kenneth Albanowski for his PPPort.pm usefull package and to Tom Lane
for his ligth.

Note: the attachment is a tar of all modified and added files in the source tree.

Regards,

Gilles DAROLD