Message-ID: <97d218e241183a7a9dd634cc30f2ec17d1191878.camel@cybertec.at>
Subject: Re: Online PostgreSQL version() updates
From: Laurenz Albe <laurenz.albe@cybertec.at>
To: Andrey Borodin <x4mmm@yandex-team.ru>, Matthias van de Meent
	 <boekewurm+postgres@gmail.com>
Cc: PostgreSQL Hackers <pgsql-hackers@lists.postgresql.org>
Date: Wed, 01 Apr 2026 14:47:19 +0200
In-Reply-To: <9A9D654D-A666-4943-B1FC-1E086AAC68C0@yandex-team.ru>
References: 
	<CAEze2WjgxD-uZrjiD7Gtp2gy=ztAOTU+xyLNJg6saYG4erP_=w@mail.gmail.com>
	 <9A9D654D-A666-4943-B1FC-1E086AAC68C0@yandex-team.ru>
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
User-Agent: Evolution 3.58.3 (3.58.3-1.fc43) 
MIME-Version: 1.0
Archived-At: 
 <https://www.postgresql.org/message-id/97d218e241183a7a9dd634cc30f2ec17d1191878.camel%40cybertec.at>
Precedence: bulk

On Wed, 2026-04-01 at 17:01 +0500, Andrey Borodin wrote:
>=20
> > On 1 Apr 2026, at 15:48, Matthias van de Meent <boekewurm+postgres@gmai=
l.com> wrote:
> >=20
> > Attached is a patch that allows superusers to update the version() of
> > their running system with a simple SQL call: SELECT
> > pg_update_version(version_num, 'version_short', 'the full version()
> > outout')
>=20
> While I find this proposal very useful, I think the interface can be impr=
oved.
>=20
> Consider SELECT pg_update_version(commit_hash) so we can do stuff like
> SELECT pg_update_version('REL_18_2') or SELECT pg_update_version('HEAD~10=
000').
> In future we can even create a bisect facility, so when user encounters a=
 bug
> in their production they can iterate over several commits to trace root c=
ause.

I don't think that has to go into the first release; perhaps such functiona=
lity
can be added later.

But the patch, as it is, is missing something important: the "internal" par=
ameters
"server_version" and "server_version_num" need to reflect the changed versi=
on.

Yours,
Laurenz Albe