Re: some pg_dump query code simplification - Mailing list pgsql-hackers

From Stephen Frost
Subject Re: some pg_dump query code simplification
Date
Msg-id 20180828222805.GQ3326@tamriel.snowman.net
Whole thread Raw
In response to Re: some pg_dump query code simplification  (Tom Lane <tgl@sss.pgh.pa.us>)
List pgsql-hackers
Greetings,

* Tom Lane (tgl@sss.pgh.pa.us) wrote:
> Stephen Frost <sfrost@snowman.net> writes:
> > * Tom Lane (tgl@sss.pgh.pa.us) 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.
>
> > I certainly agree that this would be ideal, but nonetheless, I've seen
> > multiple cases where just trying to run the query, even against a
> > current version, would have shown that it's malformed or has some issue
> > which needs fixing and today we haven't even got that.
>
> Yeah, but cases where we need to touch column C in one version and column
> D in another can't be made to pass when pg_dump is operating under a false
> assumption about the server version.  So this seems like a nonstarter.

Yes, there are cases that wouldn't work.

I'd be much happier with a complete solution, were that forthcoming.

Thanks!

Stephen

Attachment

pgsql-hackers by date:

Previous
From: Tom Lane
Date:
Subject: Re: some pg_dump query code simplification
Next
From: Thomas Munro
Date:
Subject: Re: Why hash OIDs?