Thread: 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