From: | cowwoc <cowwoc(at)bbs(dot)darktech(dot)org> |
---|---|
To: | Szymon Guz <mabewlun(at)gmail(dot)com> |
Cc: | PostgreSQL <pgsql-general(at)postgresql(dot)org> |
Subject: | Re: Why isn't Java support part of Postgresql core? |
Date: | 2014-09-19 16:40:35 |
Message-ID: | 541C5C83.2030201@bbs.darktech.org |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-general |
On 19/09/2014 4:30 AM, Szymon Guz wrote:
> I think all people here agree that adding another package to linux
> repository or an option to windows installer is OK. What some people
> disagree here is adding jre to the core postgres.
So we're in agreement.
> Oh, and btw, I've got a package named postgresql-9.3-pljava-gcj in my
> linux repo.
Good to know, but for now I'm developing primarily on Windows machines.
>> If there is a programmer who cannot install jvm/jdk on its own
>> (which is a couple of clicks on windows and linux) then I'm sure
>> that writing stored procerures in java will be even too difficult.
>
> Installing a public JVM is easy. Binding it to pl/java is not. By
> bundling a private JRE we control the default installation path
> and can therefore pre-configure pl/java to look for it in that
> location.
>
>
> The best solution would be to make different languages, like pljava6,
> pljava7, pljava8, with library path configured in the create extension
> command. This way we could use different jvms and library versions for
> each database.
That's fine with me.
>
> I'm not taking this option away from you. Power users can still do
> what they want. I'm just trying to facilitate deployment users who
> are fine with the default/typical configuration.
>
>
> So in fact you propose to create another option in the windows
> installer only, right?
Correct.
Gili
From | Date | Subject | |
---|---|---|---|
Next Message | Adarsh Sharma | 2014-09-19 18:33:30 | PROBLEM Service Alert: hostname/check_postgres_old_transaction is CRITICAL ** |
Previous Message | Jan-Pieter Cornet | 2014-09-19 15:29:49 | corruption in system tables (9.1.13) |