Обсуждение: 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