On 01/12/2011 04:22 PM, Tom Lane wrote:
Alexey Klyukin<al...@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
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
