| From: | Robert Haas <robertmhaas(at)gmail(dot)com> |
|---|---|
| To: | Noah Misch <noah(at)leadboat(dot)com> |
| Cc: | Stephen Frost <sfrost(at)snowman(dot)net>, Peter Eisentraut <peter(dot)eisentraut(at)2ndquadrant(dot)com>, "pgsql-hackers(at)postgresql(dot)org" <pgsql-hackers(at)postgresql(dot)org> |
| Subject: | Re: new tests post-feature freeze (was pgsql: Add TAP tests for pg_dump) |
| Date: | 2016-05-25 00:19:20 |
| Message-ID: | CA+Tgmobp=pvf7tQZW4yj1X1qL=ToUYZMru2jt8aOr2Cz2xGE8g@mail.gmail.com |
| Views: | Raw Message | Whole Thread | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-hackers |
On Sun, May 22, 2016 at 11:22 PM, Noah Misch <noah(at)leadboat(dot)com> wrote:
> Some or even most of the other tests would qualify under "closely related to
> ... a feature that is new in 9.6". Your 9.6 pg_dump changes affected object
> selection and catalog extraction for most object types, so I think validating
> those paths is in scope under Robert's suggestion. Testing "pg_dump
> --encoding" or "pg_dump --jobs" probably wouldn't fall in scope, because those
> features operate at arm's length from the 9.6 pg_dump changes. Expanding, for
> example, tests of postgres_fdw query deparse would certainly fall out of
> scope. That would have no apparent chance of catching a regression caused by
> the 9.6 pg_dump changes.
...although it might catch bugs in the deparsing logic, which was
heavily revised in 9.6.
--
Robert Haas
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company
| From | Date | Subject | |
|---|---|---|---|
| Next Message | David G. Johnston | 2016-05-25 00:27:04 | Re: [BUGS] BUG #14155: bloom index error with unlogged table |
| Previous Message | Tom Lane | 2016-05-25 00:08:27 | Re: BUG #14155: bloom index error with unlogged table |