| From: | Laurenz Albe <laurenz(dot)albe(at)cybertec(dot)at> |
|---|---|
| To: | Andrey Borodin <x4mmm(at)yandex-team(dot)ru>, Matthias van de Meent <boekewurm+postgres(at)gmail(dot)com> |
| Cc: | PostgreSQL Hackers <pgsql-hackers(at)lists(dot)postgresql(dot)org> |
| Subject: | Re: Online PostgreSQL version() updates |
| Date: | 2026-04-01 12:47:19 |
| Message-ID: | 97d218e241183a7a9dd634cc30f2ec17d1191878.camel@cybertec.at |
| Views: | Whole Thread | Raw Message | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-hackers |
On Wed, 2026-04-01 at 17:01 +0500, Andrey Borodin wrote:
>
> > On 1 Apr 2026, at 15:48, Matthias van de Meent <boekewurm+postgres(at)gmail(dot)com> wrote:
> >
> > 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')
>
> While I find this proposal very useful, I think the interface can be improved.
>
> 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~10000').
> 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 cause.
I don't think that has to go into the first release; perhaps such functionality
can be added later.
But the patch, as it is, is missing something important: the "internal" parameters
"server_version" and "server_version_num" need to reflect the changed version.
Yours,
Laurenz Albe
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Pavlo Golub | 2026-04-01 12:49:05 | Re[2]: [PATCH] pg_stat_statements: add last_execution_start column |
| Previous Message | Amit Kapila | 2026-04-01 12:35:01 | Re: Adding REPACK [concurrently] |