Re: [HACKERS] error message diff with Perl 5.22.0
On Thu, Jul 2, 2015 at 11:56 AM, Tom Lane wrote: > Alex Hunsaker writes: >> (What about the back branches? :D) > > Indeed. dangomushi is complaining about this in the back branches now. Yep, perl 5.22 is used there. -- Michael -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] error message diff with Perl 5.22.0
Alex Hunsaker writes: > (What about the back branches? :D) Indeed. dangomushi is complaining about this in the back branches now. regards, tom lane -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] error message diff with Perl 5.22.0
On Sat, Jun 6, 2015 at 7:03 PM, Peter Eisentraut wrote: > With the recently released Perl 5.22.0, the tests fail thus: > > -ERROR: Global symbol "$global" requires explicit package name at line 3. > -Global symbol "$other_global" requires explicit package name at line 4. > +ERROR: Global symbol "$global" requires explicit package name (did you > forget to declare "my $global"?) at line 3. > +Global symbol "$other_global" requires explicit package name (did you > forget to declare "my $other_global"?) at line 4. > CONTEXT: compilation of PL/Perl function "uses_global" > > FWIW the committed expected file seems fine to me. There is not a perl option to toggle this behavior (and even if there was, I think the resulting changes to pl/perl functions we be quite ugly). (What about the back branches? :D)
Re: [HACKERS] error message diff with Perl 5.22.0
Peter Eisentraut writes: > With the recently released Perl 5.22.0, the tests fail thus: > -ERROR: Global symbol "$global" requires explicit package name at line 3. > -Global symbol "$other_global" requires explicit package name at line 4. > +ERROR: Global symbol "$global" requires explicit package name (did you > forget to declare "my $global"?) at line 3. > +Global symbol "$other_global" requires explicit package name (did you forget > to declare "my $other_global"?) at line 4. > CONTEXT: compilation of PL/Perl function "uses_global" BTW, buildfarm member anchovy has started failing because of this. Could we get a fix in? I think the "alternate expected file" approach is fine. regards, tom lane -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] error message diff with Perl 5.22.0
On 6/6/15 10:32 PM, Alvaro Herrera wrote: > Peter Eisentraut wrote: >> With the recently released Perl 5.22.0, the tests fail thus: >> >> -ERROR: Global symbol "$global" requires explicit package name at line 3. >> -Global symbol "$other_global" requires explicit package name at line 4. >> +ERROR: Global symbol "$global" requires explicit package name (did you >> forget to declare "my $global"?) at line 3. >> +Global symbol "$other_global" requires explicit package name (did you >> forget to declare "my $other_global"?) at line 4. >> CONTEXT: compilation of PL/Perl function "uses_global" >> >> >> With PL/Python, this happens for just about every other release, and we >> usually add another expected file. I don't see anything like that for >> PL/Perl yet. Should we add a new expected file, or is there a different >> preferred solution? > > How many .sql files does this affect? Alternate expected output is > bothersome; if more than one test file is affected, I think the best is > to isolate the cases where this appears to a single .sql file, as short > as possible, so that we don't have to touch it for anything else, and so > that we don't have to touch the isolated file except for similar > changes. It's only one file. -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] error message diff with Perl 5.22.0
Peter Eisentraut wrote: > With the recently released Perl 5.22.0, the tests fail thus: > > -ERROR: Global symbol "$global" requires explicit package name at line 3. > -Global symbol "$other_global" requires explicit package name at line 4. > +ERROR: Global symbol "$global" requires explicit package name (did you > forget to declare "my $global"?) at line 3. > +Global symbol "$other_global" requires explicit package name (did you forget > to declare "my $other_global"?) at line 4. > CONTEXT: compilation of PL/Perl function "uses_global" > > > With PL/Python, this happens for just about every other release, and we > usually add another expected file. I don't see anything like that for > PL/Perl yet. Should we add a new expected file, or is there a different > preferred solution? How many .sql files does this affect? Alternate expected output is bothersome; if more than one test file is affected, I think the best is to isolate the cases where this appears to a single .sql file, as short as possible, so that we don't have to touch it for anything else, and so that we don't have to touch the isolated file except for similar changes. Also, do we need a buildfarm member running 5.22? -- Álvaro Herrerahttp://www.2ndQuadrant.com/ PostgreSQL Development, 24x7 Support, Remote DBA, Training & Services -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] error message diff with Perl 5.22.0
Alvaro Herrera wrote: > Also, do we need a buildfarm member running 5.22? Actually, I wonder if there's a way to have a buildfarm animal that runs the pl/perl tests with all supported versions of Perl, for example. This would probably require adding a new .pm file each time a new Perl is released. Is this doable? -- Álvaro Herrerahttp://www.2ndQuadrant.com/ PostgreSQL Development, 24x7 Support, Remote DBA, Training & Services -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers