Dmitry Dolgov <9erthalion6@gmail.com> writes:
> On Sun, Sep 22, 2024 at 01:15:54PM GMT, Dmitry Dolgov wrote:
>> About a new function, I think that the llvm runtime version has to be
>> shown in some form by pgsql_version. The idea is to skip an emails
>> exchange like "here is the bug report" -> "can you attach the llvm
>> version?".
I'm not in favor of that, for a couple of reasons:
* People already have expectations about what version() returns.
Some distro and forks even modify it (see eg --extra-version).
I think we risk breaking obscure use-cases if we add stuff onto that.
Having version() return something different from the PG_VERSION_STR
constant could cause other problems too, perhaps.
* Believing that it'll save us questioning a bug submitter seems
fairly naive to me. Nobody includes the result of version() unless
specifically asked for it.
* I'm not in favor of overloading version() with subsystem-related
version numbers, because it doesn't scale. Who's to say we're not
going to need the version of ICU, or libxml2, to take a couple of
obvious examples? When you take that larger view, multiple
subsystem-specific version functions seem to me to make more sense.
Maybe another idea could be a new system view?
=> select * from pg_system_version;
property | value
----------------------------------------
core version | 18.1
architecture | x86_64-pc-linux-gnu
word size | 64 bit
compiler | gcc (GCC) 12.5.0
ICU version | 60.3
LLVM version | 18.1.0
...
Adding rows to a view over time seems way less likely to cause
problems than messing with a string people probably have crufty
parsing code for.
>> If it's going to be a new separate function, I guess it won't
>> make much difference to ask either to call the new function or the
>> llvm-config, right?
I do think that if we can get a version number out of the loaded
library, that is worth doing. I don't trust the llvm-config that
happens to be in somebody's PATH to be the same version that their
PG is actually built with.
regards, tom lane
