Обсуждение: Re: System views for versions reporting

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 ...)

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

Joe Conway <mail@joeconway.com> writes:
> On 10/16/24 08:47, Peter Eisentraut wrote:
>> 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.

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