Thread: PL/Perl compilation error
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 [root@eaccess plperl]# perl Makefile.PL Writing Makefile for plperl [root@eaccess plperl]# make cc -c -I../../../src/include -I../../../src/backend -fno-strict-aliasing -D_LAR GEFILE_SOURCE -D_FILE_OFFSET_BITS=64 -O2 -DVERSION=\"0.10\" -DXS_VERSION=\"0 .10\" -fpic -I/usr/local/lib/perl5/5.6.0/i686-linux/CORE plperl.c In file included from plperl.c:76: /usr/local/lib/perl5/5.6.0/i686-linux/CORE/perl.h:467: warning: `USE_LOCALE' red efined ../../../src/include/config.h:213: warning: this is the location of the previous definition In file included from plperl.c:76: /usr/local/lib/perl5/5.6.0/i686-linux/CORE/perl.h:2027: warning: `DEBUG' redefin ed ../../../src/include/utils/elog.h:22: warning: this is the location of the previ ous definition plperl.c: In function `plperl_create_sub': plperl.c:328: `errgv' undeclared (first use in this function) plperl.c:328: (Each undeclared identifier is reported only once plperl.c:328: for each function it appears in.) plperl.c:334: `na' undeclared (first use in this function) plperl.c: In function `plperl_call_perl_func': plperl.c:444: `errgv' undeclared (first use in this function) plperl.c:450: `na' undeclared (first use in this function) plperl.c: In function `plperl_func_handler': plperl.c:654: `na' undeclared (first use in this function) plperl.c: In function `plperl_build_tuple_argument': plperl.c:2192: `na' undeclared (first use in this function) make: *** [plperl.o] Error 1 [root@eaccess plperl]# What I'm doing wrong? Regards, Alex
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
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 #
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
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
>
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 > 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
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 fixingit 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 #
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 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);
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
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
Attachment
Gilles DAROLD <gilles@darold.net> writes:
> 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 :-)
Excellent! I'll check it over and put it in the tree. Thank you.
regards, tom lane
Broke my build on UnixWare 7.1.1... May be perl version confusion... See my post to -hackers. Larry * Tom Lane <tgl@sss.pgh.pa.us> [001024 18:38]: > Gilles DAROLD <gilles@darold.net> writes: > > 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 :-) > > Excellent! I'll check it over and put it in the tree. Thank you. > > regards, tom lane -- Larry Rosenman http://www.lerctr.org/~ler Phone: +1 972-414-9812 (voice) Internet: ler@lerctr.org US Mail: 1905 Steamboat Springs Drive, Garland, TX 75044-6749
Hi, Do you use the file GNUmakefile and ppport.h I recently send to the list ? What is your version of Perl ? Could you send me output of your build ? Regards, Gilles DAROLD Larry Rosenman wrote: > Broke my build on UnixWare 7.1.1... May be perl version confusion... > > See my post to -hackers. > > Larry > * Tom Lane <tgl@sss.pgh.pa.us> [001024 18:38]: > > Gilles DAROLD <gilles@darold.net> writes: > > > 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 :-) > > > > Excellent! I'll check it over and put it in the tree. Thank you. > > > > regards, tom lane > -- > Larry Rosenman http://www.lerctr.org/~ler > Phone: +1 972-414-9812 (voice) Internet: ler@lerctr.org > US Mail: 1905 Steamboat Springs Drive, Garland, TX 75044-6749