Re: some pg_dump query code simplification
От | Andrew Dunstan |
---|---|
Тема | Re: some pg_dump query code simplification |
Дата | |
Msg-id | cd908ac0-abc0-3b29-df53-ac9773fee95d@2ndQuadrant.com обсуждение исходный текст |
Ответ на | Re: some pg_dump query code simplification (Tom Lane <tgl@sss.pgh.pa.us>) |
Ответы |
Re: some pg_dump query code simplification
|
Список | pgsql-hackers |
On 08/28/2018 06:05 PM, Tom Lane wrote: > Stephen Frost <sfrost@snowman.net> writes: >> I wonder- what if we had an option to pg_dump to explicitly tell it what >> the server's version is and then have TAP tests to run with different >> versions? > Uh ... telling it what the version is doesn't make that true, so I'd > have no confidence in a test^H^H^H^Hkluge done that way. The way > to test is to point it at an *actual* back-branch server. > > Andrew has a buildfarm module that does precisely that, although > I'm not sure what its test dataset is --- probably the regression > database from each branch. I also have a habit of doing such testing > manually whenever I touch version-sensitive parts of pg_dump. It's all the databases from a buildfarm run apart from TAP tests. Since it uses USE_MODULE_DB=1 it covers most of the contrib modules plus the standard regression db, as well as isolation test and pl_regression (which should be taught to do separate DBs for each PL if requested). There is no reason it couldn't test more. > Dunno about the idea of running the pg_dump TAP tests against back > branches. I find that code sufficiently unreadable that maintaining > several more copies of it doesn't sound like fun at all. > > Agreed. The code could do with a lot of comments. I recently looked at adding something to it and decided I had more pressing things to do. cheers andrew -- Andrew Dunstan https://www.2ndQuadrant.com PostgreSQL Development, 24x7 Support, Remote DBA, Training & Services
В списке pgsql-hackers по дате отправления: