From: | Peter Geoghegan <pg(at)bowt(dot)ie> |
---|---|
To: | Christoph Berg <myon(at)debian(dot)org>, Peter Geoghegan <pg(at)bowt(dot)ie>, pgsql-pkg-debian(at)postgresql(dot)org |
Subject: | Re: amcheck packages |
Date: | 2017-10-02 18:29:09 |
Message-ID: | CAH2-WzmO++VVtDrY1FTiSy2cNdJdMvi2OjkR5eMgZU7h2O_1kg@mail.gmail.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-pkg-debian |
On Mon, Oct 2, 2017 at 12:38 AM, Christoph Berg <myon(at)debian(dot)org> wrote:
> Putting this 0.3-2 on top of master will only work if you also do the
> "1.0" change in debian/source/format, or else dpkg will complain about
> differences between the 0.3 tarball and the checkout. (That's why I
> suggested 0.4.)
I can go with 0.4-1, then.
> Does the extension sql file have any difference between the versions?
> What I'm often seeing is that extension authors will increment the
> extension version even for C-only changes.
Yes, because we need to revoke execution permissions at the SQL level.
We're no longer checking for superuser at the C code level, and so are
following what has since become "upstream", Postgres contrib.
> If it's really the same extension, just a newer codebase, why not have
> 1.0 in PG10, and use 1.1 here. Renaming the extension somewhat implies
> it would be co-installable with the original.
They could be co-installable, by changing symbol names. There is going
to be a contrib amcheck 1.1 before too long, so if I'm not going to
change the name of the extension, I should at least make sure that the
version numbers stay in a non-overlapping range, to make sure that
there is never confusion during upgrade.
I am tempted to increment versions ahead of extension version, for
C-only changes. That would allow me to create a 0.4-1 without changing
or adding any SQL files. What do you think of that idea? Any
particular reason why I should favor extension/package version 1.0,
that I might have missed?
> (On diffing the SQL files, I see that the difference is that "PARALLEL
> RESTRICTED" got dropped, is that intended? It is not reflected in any
> of the amcheck--*--*.sql files.)
I don't believe that that's critical, since we default to unsafe. The
Postgres contrib version is PARALLEL RESTRICTED on general principle,
not because it matters. Leaving this out means I don't have to deal
with special cases on Postgres versions that don't know about
parallelism.
--
Peter Geoghegan
From | Date | Subject | |
---|---|---|---|
Next Message | Peter Geoghegan | 2017-10-02 18:36:58 | Re: amcheck packages |
Previous Message | Christoph Berg | 2017-10-02 16:09:05 | Re: amcheck packages |