The attached patch appears to fix the problem discussed in the
plperl gives error after reconnect thread in pgsql-bugs:
http://archives.postgresql.org/pgsql-bugs/2005-08/msg00133.php
Unfortunately I don't understand *why* it fixes the problem, which
means I'm not sure that it's the correct fix.
Michael Fuhr [EMAIL PROTECTED] writes:
The attached patch appears to fix the problem discussed in the
plperl gives error after reconnect thread in pgsql-bugs:
I think this patch is a good idea just on grounds of namespace
safety, so I'll go ahead and apply it. But like you, I have no
idea why
The attached patch moves the common elements of loose_embedding[]
and strict_embedding[] to a macro so they can be maintained in
one place. As Tom Lane noticed, ::_plperl_to_pg_array was missing
from strict_embedding[], which appears to be a bug.
The attached patch allows the PL/Perl regression tests to pass when
use_strict is enabled. I've also attached a variant of plperl_elog.out
to account for an elog() message that shows a different line number
when run under use_strict.
--
Michael Fuhr
Index: src/pl/plperl/sql/plperl.sql
On Mon, Jul 11, 2005 at 08:13:24PM -0600, Michael Fuhr wrote:
On Sun, Jul 10, 2005 at 12:58:24AM -0400, Bruce Momjian wrote:
I am unclear about backpatching this. We have to weigh the risks of
applying or not applying to 8.0.X. Comments?
Since 7.4, PL/Python is only available as an
On Sat, Aug 20, 2005 at 03:30:07PM -0400, Andrew Dunstan wrote:
How far back has this bug been verified? Was it in 7.4 before we made
some large changes to plperl?
Not sure -- the problem showed up with SPI, which wasn't in the
stock PL/Perl until 8.0. I haven't done tests with earlier
Peter Eisentraut wrote:
Am Sonntag, 14. August 2005 23:48 schrieb Tom Lane:
Yeah, but don't we already have some code for that (or, actually, the
reverse direction) in initdb? It's probably not perfect, but it'd be
a lot better than crashing.
The reverse direction is a lot simpler
Koichi Suzuki [EMAIL PROTECTED] writes:
Here're a couple of patches for PostgreSQL 64bit support. There're just
two extension to 64bit, size of shared memory and transaction ID.
I've applied the part of this that seemed reasonably noncontroversial,
namely the fixes to do shared memory size
Bruce Momjian pgman@candle.pha.pa.us writes:
Is there a TODO here?
Yeah:
* Fix problems with wrong runtime encoding conversion for NLS message files
One thing that occurred to me is that we might be able to simplify the
problem by adopting a project standard that all NLS message files shall
be
Michael Fuhr [EMAIL PROTECTED] writes:
The attached patch moves the common elements of loose_embedding[]
and strict_embedding[] to a macro so they can be maintained in
one place. As Tom Lane noticed, ::_plperl_to_pg_array was missing
from strict_embedding[], which appears to be a bug.
Tom Lane wrote:
Michael Fuhr [EMAIL PROTECTED] writes:
The attached patch moves the common elements of loose_embedding[]
and strict_embedding[] to a macro so they can be maintained in
one place. As Tom Lane noticed, ::_plperl_to_pg_array was missing
from strict_embedding[], which appears
Andrew Dunstan [EMAIL PROTECTED] writes:
Every perl module whose author wants strict mode (and they all should)
has to carry such a declaration, so in a sense we'd just be doing what
perl itself does, and by trying to provide a global switch we're being
unperlish.
You missed my point. I
Tom Lane wrote:
Andrew Dunstan [EMAIL PROTECTED] writes:
Every perl module whose author wants strict mode (and they all should)
has to carry such a declaration, so in a sense we'd just be doing what
perl itself does, and by trying to provide a global switch we're being
unperlish.
Andrew Dunstan [EMAIL PROTECTED] writes:
Do you expect turning it on to affect only future compilations? Or
should we recompile every function already compiled in the present
backend? I can see arguments either way.
Yeah, me too. I would definitely expect a change in the variable
(in either
14 matches
Mail list logo
