From: | Alastair Turner <minion(at)decodable(dot)me> |
---|---|
To: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
Cc: | Dmitry Dolgov <9erthalion6(at)gmail(dot)com>, pgsql-hackers(at)postgresql(dot)org |
Subject: | Re: Add llvm version into the version string |
Date: | 2024-09-24 12:53:49 |
Message-ID: | CAC0GmyzC2KkO=UAyVy7Zq15dw4C-xW23d8EnUjD9nrQsS5dsww@mail.gmail.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
On Mon, 23 Sept 2024 at 19:45, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> wrote:
...
> 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
> ...
>
>
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.
Regards
Alastair
From | Date | Subject | |
---|---|---|---|
Next Message | Heikki Linnakangas | 2024-09-24 13:09:39 | Re: AIX support |
Previous Message | Daniel Gustafsson | 2024-09-24 12:31:30 | Re: index_delete_sort: Unnecessary variable "low" is used in heapam.c |