Re: Add llvm version into the version string

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

In response to

Responses

Browse pgsql-hackers by date

  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