| From: | Peter Geoghegan <pg(at)heroku(dot)com> |
|---|---|
| To: | Jim Nasby <Jim(dot)Nasby(at)bluetreble(dot)com> |
| Cc: | Pg Hackers <pgsql-hackers(at)postgresql(dot)org>, Robert Haas <robertmhaas(at)gmail(dot)com> |
| Subject: | Re: Bug in bttext_abbrev_convert() |
| Date: | 2015-07-01 00:36:31 |
| Message-ID: | CAM3SWZQWG7X6K=EEwqbzMueuG5LiaQdKAonYL5BoOWFTEWH=3A@mail.gmail.com |
| Views: | Raw Message | Whole Thread | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-hackers |
On Tue, Jun 30, 2015 at 5:25 PM, Jim Nasby <Jim(dot)Nasby(at)bluetreble(dot)com> wrote:
> Isn't this the kind of thing Coverty's supposed to find?
I don't know, but in general I'm not very excited about static
analysis tools. The best things that they have going for them is that
they're available, and don't require test coverage in the same way as
running the regression tests with Valgrind enabled.
There is no real testing of sorting in the regression tests. It would
be nice to have a way of generating a large and varied selection of
sort operations programmatically, to catch this kind of thing.
pg_regress is not really up to it. The same applies to various other
cases where having a lot of "expected" output makes using pg_regress
infeasible.
--
Peter Geoghegan
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Peter Eisentraut | 2015-07-01 01:33:28 | Re: pg_basebackup and replication slots |
| Previous Message | Jim Nasby | 2015-07-01 00:25:36 | Re: Bug in bttext_abbrev_convert() |