Greetings,
* Andrew Dunstan (andrew.duns...@2ndquadrant.com) wrote:
> On 08/28/2018 06:05 PM, Tom Lane wrote:
> >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
Greetings,
* Andrew Dunstan (andrew.duns...@2ndquadrant.com) wrote:
> On 08/28/2018 06:10 PM, Stephen Frost wrote:
> >>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
Peter Eisentraut writes:
> OK, updated patch attached. If the updated style is acceptable, I'll
> start running more extensive tests against the older branches.
Looks sane to me.
regards, tom lane
On 28/08/2018 23:43, Tom Lane wrote:
> I think I had this discussion already with somebody, but ... I do not
> like this style at all:
>
> tbinfo->attidentity[j] = (i_attidentity >= 0 ? *(PQgetvalue(res,
> j, i_attidentity)) : '\0');
OK, updated patch attached. If the updated style
On 08/28/2018 06:10 PM, Stephen Frost wrote:
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
On 08/28/2018 06:05 PM, Tom Lane wrote:
Stephen Frost 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
Greetings,
* Tom Lane (t...@sss.pgh.pa.us) wrote:
> Stephen Frost writes:
> > * Tom Lane (t...@sss.pgh.pa.us) wrote:
> >> Stephen Frost 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
Stephen Frost writes:
> * Tom Lane (t...@sss.pgh.pa.us) wrote:
>> Stephen Frost 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
Greetings,
* Tom Lane (t...@sss.pgh.pa.us) wrote:
> Stephen Frost 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
Stephen Frost 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
Greetings,
* Tom Lane (t...@sss.pgh.pa.us) wrote:
> Peter Eisentraut writes:
> > There is a lot of version dependent code in pg_dump now, especially
> > per-version queries. The way they were originally built was that we
> > just have an entirely separate query per version. But as the number
Peter Eisentraut writes:
> There is a lot of version dependent code in pg_dump now, especially
> per-version queries. The way they were originally built was that we
> just have an entirely separate query per version. But as the number of
> versions and the size of the query grows, this becomes
There is a lot of version dependent code in pg_dump now, especially
per-version queries. The way they were originally built was that we
just have an entirely separate query per version. But as the number of
versions and the size of the query grows, this becomes unwieldy.
So I tried, as an
13 matches
Mail list logo
