Re: pg_upgrade test for binary compatibility of core data types - Mailing list pgsql-hackers

From Jacob Champion
Subject Re: pg_upgrade test for binary compatibility of core data types
Date
Msg-id e508464c63689fb67311a3ec929e9b77f01018aa.camel@vmware.com
Whole thread Raw
In response to Re: pg_upgrade test for binary compatibility of core data types  (Jacob Champion <pchampion@vmware.com>)
List pgsql-hackers
On Fri, 2021-07-16 at 16:21 +0000, Jacob Champion wrote:
> On Fri, 2021-04-30 at 13:33 -0500, Justin Pryzby wrote:
> > On Sat, Mar 06, 2021 at 03:01:43PM -0500, Tom Lane wrote:
> > > v4-0001 mostly teaches test.sh about specific changes that have to be
> > > made to historic versions of the regression database to allow them
> > > to be reloaded into current servers.  As already discussed, this is
> > > really duplicative of knowledge that's been embedded into the buildfarm
> > > client over time.  It'd be better if we could refactor that so that
> > > the buildfarm shares a common database of these actions with test.sh.
> > > And said database ought to be in our git tree, so committers could
> > > fix problems without having to get Andrew involved every time.
> > > I think this could be represented as a psql script, at least in
> > > versions that have psql \if (but that came in in v10, so maybe
> > > we're there already).
> > 
> > I started this.  I don't know if it's compatible with the buildfarm client, but
> > I think any issues maybe can be avoided by using "IF EXISTS".
> 
> I'm going to try pulling this into a psql script today and see how far
> I get.

I completely misread this exchange -- you already did this in 0004.
Sorry for the noise.

--Jacob

pgsql-hackers by date:

Previous
From: Jacob Champion
Date:
Subject: Re: pg_upgrade test for binary compatibility of core data types
Next
From: Pavel Stehule
Date:
Subject: Re: proposal: enhancing plpgsql debug API - returns text value of variable content