=> 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 ...
A view like that sounds very useful.
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.
Since the build and runtime versions may differ for some things like llvm, libxml2 and the interpreters behind some of the PLs, it may be valuable to expand the view and show two values - a build time (or configure time) value and a runtime value for these.
