On 01/12/2011 04:22 PM, Tom Lane wrote:
> Alexey Klyukin<alexk@commandprompt.com> writes:
>> Since almost everyone votes for making the new behavior a default option I'm
>> inclined to do that change, although I'm against throwing out the
>> compatibility option. There are many other reasons except for PL/Perl for
>> people to upgrade to 9.1, let's not force them to rewrite their Perl code
>> if they were not planning to do that.
> IMO a GUC for this completely sucks, because if you do need to convert
> your Perl functions, the only way to do it is to have a flag day wherein
> they all change at once. And what about people writing Perl functions
> that they'd like to give to other people?
>
> If you have to have a flag, the only useful sort of flag is one that can
> be attached to individual functions. Compare what we did for
> plpgsql.variable_conflict in 9.0. I don't know how practical that will
> be in plperl, though.
I don't see why it should be terribly difficult. We have the source code
and we have a couple of powerful regex engines. Determining it it has a
string in some position like
# pragma: plperl.arrays_as_strings
doesn't seem onerous. It's just a SMOC.
It's not too hard to imagine other things that might be useful for.
> I thought the idea of overloading the string representation to look like
> the old style was a cute solution. If we don't have anyone at hand who
> knows how to do that, let's find someone who does. Not break our users'
> code because we're too lazy to find out how to do it properly.
>
>
What I was casting a bit of doubt on upthread was whether or not this
would work without possibly breaking some code, in possibly silent or
obscure ways. If I'm wrong about that, then by all means let's use some
perl Magic (that's a technical term) to achieve this. IIRC Alex recently
posted some code that might be instructive about this.
cheers
andrew
