|From:||Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>|
|To:||Andres Freund <andres(at)anarazel(dot)de>|
|Cc:||Catalin Iacob <iacobcatalin(at)gmail(dot)com>, Thomas Munro <thomas(dot)munro(at)enterprisedb(dot)com>, Pg Hackers <pgsql-hackers(at)postgresql(dot)org>, Pierre Ducroquet <p(dot)psql(at)pinaraf(dot)info>|
|Subject:||Re: JIT compiling with LLVM v11|
|Views:||Raw Message | Whole Thread | Download mbox | Resend email|
Andres Freund <andres(at)anarazel(dot)de> writes:
> On 2018-03-15 12:33:08 -0400, Tom Lane wrote:
>> The "software collections" stuff was still in its infancy when I left
>> Red Hat, so things might've changed, but I'm pretty sure at the time
>> it was verboten for any mainstream package to depend on an SCL one.
> But we won't get PG 11 into RHEL7.x either way, no?
Well, they've been known to back-port newer releases of PG into older
RHEL; I wouldn't necessarily assume it'd happen for 11, but maybe 12
or beyond could be made available for RHEL7 at some point.
>> But they very probably wouldn't want postgresql depending on a
>> compiler package even if the dependency was mainstream, so I rather
>> doubt that you'll ever see an --enable-jit PG build out of there,
>> making this most likely moot as far as the official RH package goes.
>> I don't know what Devrim's opinion might be about PGDG.
> It'd be a build not runtime dependency, doesn't that change things?
How could it not be a runtime dependency? You're not proposing that
we'd embed all of LLVM into a Postgres package are you? If you are, be
assured that Red Hat will *never* ship that. Static linking/embedding of
one package in another is forbidden for obvious maintainability reasons.
I would think that other distros have similar policies.
regards, tom lane
|Next Message||Nikita Glukhov||2018-03-15 17:04:07||Re: SQL/JSON: functions|
|Previous Message||Alvaro Herrera||2018-03-15 16:39:52||Re: chained transactions|