Re: upcoming API changes for LLVM 12

From: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
To: Andres Freund <andres(at)anarazel(dot)de>
Cc: Alvaro Herrera <alvherre(at)alvh(dot)no-ip(dot)org>, pgsql-hackers(at)postgresql(dot)org
Subject: Re: upcoming API changes for LLVM 12
Date: 2020-10-16 21:04:56
Message-ID: 38284.1602882296@sss.pgh.pa.us
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

Andres Freund <andres(at)anarazel(dot)de> writes:
> A related question is whether it'd be time to prune the oldest supported
> LLVM version. 3.9.0 was released 2016-08-31 (and 3.9.1, the only point
> release, was 2016-12-13). There's currently no *pressing* reason to
> reduce it, but it is the cause of few #ifdefs - but more importantly it
> increases the test matrix.

> I'm inclined to just have a deterministic policy that we apply around
> release time going forward. E.g. don't support versions that are newer
> than the newest available LLVM version in the second newest
> long-term-supported distribution release of RHEL, Ubuntu, Debian?

Meh. I do not think these should be mechanistic one-size-fits-all
decisions. A lot hinges on just how messy it is to continue support
for a given tool. Moreover, the policy you propose above is
completely out of line with our approach to every other toolchain
we use.

I'd rather see an approach along the lines of "it's time to drop
support for LLVM version X because it can't do Y", rather than
"... because Z amount of time has passed".

regards, tom lane

In response to

Browse pgsql-hackers by date

  From Date Subject
Next Message Justin Pryzby 2020-10-16 21:05:12 Re: should INSERT SELECT use a BulkInsertState?
Previous Message Peter Geoghegan 2020-10-16 20:58:01 Re: Deleting older versions in unique indexes to avoid page splits