Thread

PL/Perl compilation error

Alex Guryanow <gav@nlr.ru> — 2000-09-02T08:47:58Z

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

Re: PL/Perl compilation error

Tom Lane <tgl@sss.pgh.pa.us> — 2000-09-02T16:48:46Z

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

Re: PL/Perl compilation error

Tom Lane <tgl@sss.pgh.pa.us> — 2000-09-02T23:33:42Z

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

Re: PL/Perl compilation error

Jan Wieck <janwieck@yahoo.com> — 2000-09-02T23:53:48Z

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 #

Re: PL/Perl compilation error

Jan Wieck <janwieck@yahoo.com> — 2000-09-03T14:04:04Z

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 #

Re: PL/Perl compilation error

Gilles Darold <gilles@darold.net> — 2000-09-04T12:29:33Z

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
>

Report of performance on Alpha vs. Intel

Steve Wolfe <steve@iboats.com> — 2000-09-05T17:14:27Z

   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

Re: Report of performance on Alpha vs. Intel

Mitch Vincent <mitch@venux.net> — 2000-09-05T17:35:57Z

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
>
>
>

Re: Report of performance on Alpha vs. Intel

Steve Wolfe <steve@iboats.com> — 2000-09-05T17:42:09Z

> 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

Re: Report of performance on Alpha vs. Intel

Zeljko Trogrlic <zeljko@post.hinet.hr> — 2000-09-05T19:00:46Z

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

Re: PL/Perl compilation error

Bruce Momjian <pgman@candle.pha.pa.us> — 2000-10-16T16:50:47Z

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

Re: PL/Perl compilation error

Gilles Darold <gilles@darold.net> — 2000-10-16T17:34:41Z

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

Re: [GENERAL] PL/Perl compilation error

Bruce Momjian <pgman@candle.pha.pa.us> — 2000-10-16T18:36:45Z

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

Re: PL/Perl compilation error

Tom Lane <tgl@sss.pgh.pa.us> — 2000-10-16T20:07:17Z

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

Re: PL/Perl compilation error

Gilles Darold <gilles@darold.net> — 2000-10-17T10:52:58Z

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

Re: [GENERAL] PL/Perl compilation error

Gilles Darold <gilles@darold.net> — 2000-10-17T11:12:51Z

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

do triggers/procedures run instantly?

chris markiewicz <cmarkiew@commnav.com> — 2000-10-17T11:37:33Z

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

Re: PL/Perl compilation error

Tom Lane <tgl@sss.pgh.pa.us> — 2000-10-17T14:32:49Z

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

Re: PL/Perl compilation error

alex@pilosoft.com — 2000-10-17T15:11:32Z

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

Re: PL/Perl compilation error

Tom Lane <tgl@sss.pgh.pa.us> — 2000-10-17T15:28:46Z

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

PL/Perl compilation error

Gilles Darold <gilles@darold.net> — 2000-10-24T10:51:24Z

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

Re: PL/Perl compilation error

Tom Lane <tgl@sss.pgh.pa.us> — 2000-10-24T12:39:44Z

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

Re: Re: PL/Perl compilation error

Larry Rosenman <ler@lerctr.org> — 2000-10-25T01:17:22Z

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

Re: Re: PL/Perl compilation error

Gilles Darold <gilles@darold.net> — 2000-10-25T08:30:42Z

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