Andrew Dunstan [EMAIL PROTECTED] writes:
The version I tested against is 5.8.8 - the latest stable release. The
5.8 series started in 2003 from what I can see - if anyone has a
sufficiently old system that they can test on 5.6.2 that will be useful.
I got around to trying it with a dusty
-BEGIN PGP SIGNED MESSAGE-
Hash: RIPEMD160
Tom Lane reports:
The version I tested against is 5.8.8 - the latest stable release. The
5.8 series started in 2003 from what I can see - if anyone has a
sufficiently old system that they can test on 5.6.2 that will be useful.
I got
I wrote:
I got around to trying it with a dusty 5.6.1 I have laying about on my
HPPA machine, and the news is not good: CREATE LANGUAGE plperl dumps
core deep inside libperl. With or without this patch.
As best I can tell at the moment, I have not tested 5.6.1 with anything
later than our
Tom Lane wrote:
I wrote:
I got around to trying it with a dusty 5.6.1 I have laying about on my
HPPA machine, and the news is not good: CREATE LANGUAGE plperl dumps
core deep inside libperl. With or without this patch.
As best I can tell at the moment, I have not tested 5.6.1
On Sat, 1 Dec 2007, Tom Lane wrote:
I wrote:
I got around to trying it with a dusty 5.6.1 I have laying about on my
HPPA machine, and the news is not good: CREATE LANGUAGE plperl dumps
core deep inside libperl. With or without this patch.
As best I can tell at the moment, I have not tested
I wrote:
OK, I have a fairly ugly manual workaround, that I don't yet
understand, but seems to work for me.
In your session, run the following code before you do anything else:
CREATE OR REPLACE FUNCTION test(text) RETURNS bool LANGUAGE plperl as $$
return shift =~ /\xa9/i ? 'true' :
On Thu, Nov 29, 2007 at 12:39:30AM -0500, Andrew Dunstan wrote:
The attached patch works for me to eliminate the errors. Please test ASAP.
tested, works for me:
#v+
# CREATE OR REPLACE FUNCTION test(TEXT) RETURNS bool language plperl as $$
return (shift =~ /[a-ząćęłńóśźżĄĆĘŁŃŚÓŹŻ0-9_-]+/i) || 0;
Tom Lane wrote:
Andrew Dunstan [EMAIL PROTECTED] writes:
+* Fill in just enough information to set up this perl
+* function in the safe container and call it.
+* For some reason not entirely clear, it prevents
errors
On Thu, 29 Nov 2007, Andrew Dunstan wrote:
The version I tested against is 5.8.8 - the latest stable release. The
5.8 series started in 2003 from what I can see - if anyone has a
sufficiently old system that they can test on 5.6.2 that will be useful.
I've got a 5.6.1 perl here, but it
-BEGIN PGP SIGNED MESSAGE-
Hash: RIPEMD160
Just as a followup, I reported this as a bug and it is
being looked at and discussed:
http://rt.perl.org/rt3//Public/Bug/Display.html?id=47576
Appears there is no easy resolution yet.
- --
Greg Sabino Mullane [EMAIL PROTECTED]
PGP Key:
Greg Sabino Mullane wrote:
Just as a followup, I reported this as a bug and it is
being looked at and discussed:
http://rt.perl.org/rt3//Public/Bug/Display.html?id=47576
Appears there is no easy resolution yet.
We might be able to do something with the suggested workaround. I will
Andrew Dunstan wrote:
Greg Sabino Mullane wrote:
Just as a followup, I reported this as a bug and it is being looked
at and discussed:
http://rt.perl.org/rt3//Public/Bug/Display.html?id=47576
Appears there is no easy resolution yet.
We might be able to do something with the
Andrew Dunstan wrote:
Andrew Dunstan wrote:
Greg Sabino Mullane wrote:
Just as a followup, I reported this as a bug and it is being looked
at and discussed:
http://rt.perl.org/rt3//Public/Bug/Display.html?id=47576
Appears there is no easy resolution yet.
We might be able to do
Andrew Dunstan [EMAIL PROTECTED] writes:
+ * Fill in just enough information to set up this perl
+ * function in the safe container and call it.
+ * For some reason not entirely clear, it prevents
errors that
+
-BEGIN PGP SIGNED MESSAGE-
Hash: RIPEMD160
Ugh, in testing I see some nastiness here without any explicit
require. It looks like there's an implicit require if the text
contains certain chars.
Exactly.
Looks like it's going to be very hard, unless someone has some
brilliant
Greg Sabino Mullane wrote:
Ugh, in testing I see some nastiness here without any explicit
require. It looks like there's an implicit require if the text
contains certain chars.
Exactly.
Looks like it's going to be very hard, unless someone has some
brilliant insight I'm missing
Andrew Dunstan [EMAIL PROTECTED] writes:
I tried something like that briefly and it failed. The trouble is, I
think, that since the engine tries a require it fails on the op test
before it even looks to see if the module is already loaded.
I think we have little choice but to report this as
-BEGIN PGP SIGNED MESSAGE-
Hash: RIPEMD160
hubert depesz lubaczewski writes:
...
return (shift =~ /[a-z0-9_-]+/i) || 0;
...
'require' trapped by operation mask at line 15.
it looks strange - what require?
As you guessed, it's trying to do load the utf8 pragma, and failing
as
Greg Sabino Mullane wrote:
Yes, we might want to consider making utf8 come pre-loaded for plperl. There
is no direct or easy way to do it (we don't have finer-grained control than
the 'require' opcode), but we could probably dial back restrictions,
'use' it, and then reset the Safe
Andrew Dunstan wrote:
Greg Sabino Mullane wrote:
Yes, we might want to consider making utf8 come pre-loaded for
plperl. There is no direct or easy way to do it (we don't have
finer-grained control than the 'require' opcode), but we could
probably dial back restrictions, 'use' it, and
Andrew Dunstan wrote:
Ugh, in testing I see some nastiness here without any explicit
require. It looks like there's an implicit require if the text
contains certain chars. I'll see what I can do to fix the bug,
although I'm not sure if it's possible.
Looks like it's going to be very
21 matches
Mail list logo
