Thread: PGXS testing upgrade paths
If there's a better list than this, please let me know, but I figured hackers is appropriate since the extension building infrastructure is documented in core. While working on an in-house extension I realized that while PGXS provides the standard regression test infrastructure, I'm not aware of an automatic or standard way to test all upgrade paths provided by the extension. Is there something I'm missing? Or an approach people like (I suppose the simplest way would be "manually" executing the upgrade files in a regress test, but that seems tedious). Thanks, James
James Coleman <jtc331@gmail.com> writes: > If there's a better list than this, please let me know, but I figured > hackers is appropriate since the extension building infrastructure is > documented in core. > While working on an in-house extension I realized that while PGXS > provides the standard regression test infrastructure, I'm not aware of > an automatic or standard way to test all upgrade paths provided by the > extension. The recommended way to deal with updates these days is to leave the original extension script as-is and just write update scripts (1.0--1.1, 1.1--1.2, etc). That way, application of the updates is tested automatically every time you do CREATE EXTENSION. Now, if you also want to check that the intermediate states still behave as intended, I don't see much of a solution that doesn't involve custom test scaffolding. regards, tom lane
On Mon, Sep 21, 2020 at 11:36 AM Tom Lane <tgl@sss.pgh.pa.us> wrote: > > James Coleman <jtc331@gmail.com> writes: > > If there's a better list than this, please let me know, but I figured > > hackers is appropriate since the extension building infrastructure is > > documented in core. > > > While working on an in-house extension I realized that while PGXS > > provides the standard regression test infrastructure, I'm not aware of > > an automatic or standard way to test all upgrade paths provided by the > > extension. > > The recommended way to deal with updates these days is to leave the > original extension script as-is and just write update scripts > (1.0--1.1, 1.1--1.2, etc). That way, application of the updates > is tested automatically every time you do CREATE EXTENSION. Ah, so just don't add a new 1.2 file, etc. That also implies not having more direct upgrade paths (e.g., 1.0--1.2)? > Now, if you also want to check that the intermediate states still > behave as intended, I don't see much of a solution that doesn't > involve custom test scaffolding. Yeah, I'm not so much concerned about intermediate states so much as multiple upgrade paths and/or multiple single-version install files (which you replied to already above). James
James Coleman <jtc331@gmail.com> writes: > On Mon, Sep 21, 2020 at 11:36 AM Tom Lane <tgl@sss.pgh.pa.us> wrote: >> The recommended way to deal with updates these days is to leave the >> original extension script as-is and just write update scripts >> (1.0--1.1, 1.1--1.2, etc). That way, application of the updates >> is tested automatically every time you do CREATE EXTENSION. > Ah, so just don't add a new 1.2 file, etc. > That also implies not having more direct upgrade paths (e.g., 1.0--1.2)? Right. Once the accumulation of cruft starts to impact install time substantially, maybe you want to roll things up to a new base version. But at least with the contrib modules we've found that it's seldom worth the trouble. regards, tom lane