Subject: Re: System views for versions reporting

From: Joe Conway <[email-masked]>
Date: Wed, 16 Oct 2024 09:31:58 -0400

On 10/16/24 08:47, Peter Eisentraut wrote:
> On 06.10.24 17:36, Dmitry Dolgov wrote:
>> Based on the feedback in [1], here is my attempt at implementing system
>> views for versions reporting. It adds pg_system_versions for showing
>> things like core version, compiler, LLVM, etc, and pg_system_libraries
>> for showing linked shared objects.
> 
> Is a system view the right interface?  For example, in pgbouncer we just
> added it to the version output:
> 
> $ pgbouncer --version
> PgBouncer 1.18.0
> libevent 2.1.12-stable
> adns: c-ares 1.19.0
> tls: OpenSSL 3.3.2 3 Sep 2024
> 
> That way, you can get this information without having to start a server
> instance.  (Maybe you can't start a server instance because it just
> crashed because of some library version issue ...)

While it is also useful to be able to get the info without being able to 
start the server, I think that would be an addition not a replacement. 
When you have a fleet with no direct access to run shell commands, being 
able to get this info via SQL is valuable.

-- 
Joe Conway
PostgreSQL Contributors Team
RDS Open Source Databases
Amazon Web Services: https://aws.amazon.com

---

From: Tom Lane <[email-masked]>
Date: Wed, 16 Oct 2024 10:35:40 -0400

> able to get this info via SQL is valuable.

Yeah.  In addition, I envisioned that this might include information
that's only readily available at runtime.  Don't have a concrete
example at hand (-ENOCAFFEINE) but I think that --version is
necessarily going to be exceedingly constrained in what it can do.

Another problem is that, just like with version(), there is already
code making assumptions about what --version will output.  Most of
that is under our control, but perhaps not all.  The main value
of a new system view, IMV, is that it's a completely green field
for us to define the contents of.

			regards, tom lane