Make all Perl warnings fatal
There are a lot of Perl scripts in the tree, mostly code generation
and TAP tests. Occasionally, these scripts produce warnings. These
are probably always mistakes on the developer side (true positives).
Typical examples are warnings from genbki.pl or related when
Alexander Korotkov writes:
> On Fri, Dec 29, 2023 at 10:13 PM Jeff Davis wrote:
>> This seems to be causing problems in the buildfarm:
>> Use of uninitialized value $ENV{"PG_TEST_EXTRA"} in pattern match
>> (m//) at t/001_mutated_bindpasswd.pl line 23.
> It seems to cause failures for many
In pg_dump, don't dump a stats object unless dumping underlying table.
If the underlying table isn't being dumped, it's useless to dump
an extended statistics object; it'll just cause errors at restore.
We have always applied similar policies to, say, indexes.
(When and if we get cross-table
In pg_dump, don't dump a stats object unless dumping underlying table.
If the underlying table isn't being dumped, it's useless to dump
an extended statistics object; it'll just cause errors at restore.
We have always applied similar policies to, say, indexes.
(When and if we get cross-table
In pg_dump, don't dump a stats object unless dumping underlying table.
If the underlying table isn't being dumped, it's useless to dump
an extended statistics object; it'll just cause errors at restore.
We have always applied similar policies to, say, indexes.
(When and if we get cross-table
In pg_dump, don't dump a stats object unless dumping underlying table.
If the underlying table isn't being dumped, it's useless to dump
an extended statistics object; it'll just cause errors at restore.
We have always applied similar policies to, say, indexes.
(When and if we get cross-table
In pg_dump, don't dump a stats object unless dumping underlying table.
If the underlying table isn't being dumped, it's useless to dump
an extended statistics object; it'll just cause errors at restore.
We have always applied similar policies to, say, indexes.
(When and if we get cross-table
In pg_dump, don't dump a stats object unless dumping underlying table.
If the underlying table isn't being dumped, it's useless to dump
an extended statistics object; it'll just cause errors at restore.
We have always applied similar policies to, say, indexes.
(When and if we get cross-table
On Fri, 2023-12-29 at 17:46 +, Peter Eisentraut wrote:
> Make all Perl warnings fatal
This seems to be causing problems in the buildfarm:
Use of uninitialized value $ENV{"PG_TEST_EXTRA"} in pattern match
(m//) at t/001_mutated_bindpasswd.pl line 23.
Regards,
Jeff Davis
On Fri, Dec 29, 2023 at 10:13 PM Jeff Davis wrote:
> On Fri, 2023-12-29 at 17:46 +, Peter Eisentraut wrote:
> > Make all Perl warnings fatal
>
> This seems to be causing problems in the buildfarm:
>
> Use of uninitialized value $ENV{"PG_TEST_EXTRA"} in pattern match
> (m//) at
Follow-up fixes for "Make all Perl warnings fatal"
Mostly, we need to check whether $ENV{PG_TEST_EXTRA} is set before
doing regular expression matches against it.
Branch
--
master
Details
---
https://git.postgresql.org/pg/commitdiff/9d49837d7144e27ad8ea8918acb28f9872cb1585
Modified
On 29.12.23 23:41, Tom Lane wrote:
Alexander Korotkov writes:
On Fri, Dec 29, 2023 at 10:13 PM Jeff Davis wrote:
This seems to be causing problems in the buildfarm:
Use of uninitialized value $ENV{"PG_TEST_EXTRA"} in pattern match
(m//) at t/001_mutated_bindpasswd.pl line 23.
It seems to
Fix collate.windows.win1252 test.
Do not rely on the OS recognizing a particular locale; find the right
locale by querying the "en_US" collation.
Author: Alexander Lakhin
Reported-by: Alexander Lakhin
Discussion: https://postgr.es/m/ae73f6f5-8221-c112-4640-5cda812a6...@gmail.com
Branch
--
13 matches
Mail list logo
