Обсуждение: Is there a way to use "pack" in pl/perl without resorting to pl/perlu?

I created a function that does some heavy string manipulation, so I needed to use pl/perl rather than pl/pgsql.

I'm not experienced in perl, but the function works well when used as an independent perl subroutine - it depends only
onits arguments. I use the Encode package (in postgresql configuration). 

But my use of the "pack" function causes a Safe error. Apparently "pack" and "unpack" are in the operator mask.

Is there any way to remove them from that mask? I don't want to use pl/perlu - it's too unsafe, I think, and its
runningenvironment is different. I just want these two operators. 

This is what I'm using "pack" for: I convert a string in the format '43414C4C5F494445' into a binary string, and then,
givena matching text encoding, use "decode" to convert it to proper unicode. 


TIA,
Herouth

Herouth Maoz <herouth@unicell.co.il> writes:
> I created a function that does some heavy string manipulation, so I needed to use pl/perl rather than pl/pgsql.
> I'm not experienced in perl, but the function works well when used as an independent perl subroutine - it depends
onlyon its arguments. I use the Encode package (in postgresql configuration). 

> But my use of the "pack" function causes a Safe error. Apparently "pack" and "unpack" are in the operator mask.

> Is there any way to remove them from that mask?

My recollection is that they're intentionally excluded because they
would otherwise be security holes --- there are some format codes that
allow direct access to memory, or something like that.

            regards, tom lane

-----BEGIN PGP SIGNED MESSAGE-----
Hash: RIPEMD160


Tom Lane replied:
> My recollection is that they're intentionally excluded because they
> would otherwise be security holes --- there are some format codes that
> allow direct access to memory, or something like that.

They are not part of the standard "base core" opcode group, but part
of the "still_to_be_decided" group, because they can create and use
memory pointers. It's possible that they may someday get moved out
of this group, in which case they will suddenly start working :)

Herouth Maoz wrote:
> Anyway, I replaced the functionality with
> $content =~ s/([a-fA-F0-9]{2})/chr(hex($1))/eg;
> which seems to be doing the same thing as unpack( "H*", $content )

They are not doing the same thing, so be careful. :)

> I suspect it's less efficient than unpack, and I hope the function
> I created won't be too slow for use inside a trigger.

You should be fine with either one. While the unpack is indeed
around 3x faster, a simple s/// like the above still runs at over
220,000 times per second on my slow box, so I would not worry
about the speed. Remember in general to add a /o to the end of your
regex if the first part is constant to avoid unneeded recomplilation.

- --
Greg Sabino Mullane greg@turnstep.com
End Point Corporation http://www.endpoint.com/
PGP Key: 0x14964AC8 201209131324
http://biglumber.com/x/web?pk=2529DF6AB8F79407E94445B4BC9B906714964AC8
-----BEGIN PGP SIGNATURE-----

iEYEAREDAAYFAlBSGn4ACgkQvJuQZxSWSsiLCQCePwOEYvm52IdIc3tQh5KafrfR
vnYAn0zufZffao1VxhKwquVi6OkIHdz5
=7BQ8
-----END PGP SIGNATURE-----