There are roughly three weeks left until the feature freeze on August 1.
If people are working on items, they should be announced before August
1, and the patches submitted by August 1. If the patch is large, it
should be discussed now and an intermediate patch posted to the lists
soon.

FYI, we don't have many major features ready for 8.2.

--
Bruce Momjian bruce@momjian.us
EnterpriseDB http://www.enterprisedb.com

+ If your life is a hard drive, Christ can be your backup. +

---------------------------(end of broadcast)---------------------------
TIP 5: don't forget to increase your free space map settings

I'd like to submit PL/Java into core for 8.2 if possible. Personally, I see the following
action items to make it happen:

1. A "hackers" discussion to resolve any issues with the submission.

Provided that #1 has a positive outcome:

2. The PL/Java CVS must be moved from gborg and become part of the PostgreSQL CVS (can this
be done with version history intact?).
3. The regression tests need some work in order to fit in with the build farm.
4. Documentation must be ripped from the PL/Java Wiki and transformed into the format used
by PostgreSQL.
5. I'll need committer rights to the PL/Java part in order to maintain it.
6. The pljava-dev mailing list, currently at gborg, must (perhaps) be moved also. An
alternative is to remove it and instead refer to jdbc, general, and hackers.

Given guidance, I'll do the steps #3 and #4.

External dependencies:
Platforms where PL/Java is ported must either support GCJ 4.0 or higher or have a Java
Runtime Environment 1.4.2 or higher installed.

Regards,
Thomas Hallgren

Bruce Momjian wrote:
> There are roughly three weeks left until the feature freeze on August 1.
> If people are working on items, they should be announced before August
> 1, and the patches submitted by August 1. If the patch is large, it
> should be discussed now and an intermediate patch posted to the lists
> soon.
>
> FYI, we don't have many major features ready for 8.2.
>
> --
> Bruce Momjian bruce@momjian.us
> EnterpriseDB http://www.enterprisedb.com
>
> + If your life is a hard drive, Christ can be your backup. +
>
> ---------------------------(end of broadcast)---------------------------
> TIP 5: don't forget to increase your free space map settings
>


---------------------------(end of broadcast)---------------------------
TIP 1: if posting/reading through Usenet, please send an appropriate
subscribe-nomail command to majordomo@postgresql.org so that your
message can get through to the mailing list cleanly

Thomas Hallgren <thomas@tada.se> writes:
> I'd like to submit PL/Java into core for 8.2 if possible. Personally, I see the following
> action items to make it happen:

What about licensing issues? Does PL/Java work with any entirely-open-source
JVMs? If not, what is the legal situation for distributing PG+PL/Java?

I'm also a bit concerned about size. By my count, lines of source code:

plpgsql 19890
plperl 4902
plpython 4163
pltcl 4498
pljava 1.3.0 38711

IOW pljava is (already) bigger than the other four PLs put together.

I'm inclined to think that pljava is best off staying as a separate
project.

regards, tom lane

---------------------------(end of broadcast)---------------------------
TIP 2: Don't 'kill -9' the postmaster

Tom,

Tom Lane wrote:
> IOW pljava is (already) bigger than the other four PLs put together.
>
> I'm inclined to think that pljava is best off staying as a separate
> project.

I was very confused some recent PL/Java versions can't be compiled
because of PostgreSQL internal changes.

If people think pl/java is important for PostgreSQL,
pl/java should be included in PG core tree,
and should have its regression tests.

I think PL should be integrated with core tightly.

Thanks.
--
NAGAYASU Satoshi <nagayasus@nttdata.co.jp>
Phone: +81-3-3523-8122


---------------------------(end of broadcast)---------------------------
TIP 9: In versions below 8.0, the planner will ignore your desire to
choose an index scan if your joining column's datatypes do not
match

Thomas Hallgren wrote:
>
> 5. I'll need committer rights to the PL/Java part in order to maintain
> it.


Does our CVS setup cater for seggregated rights like this? Or would that
be done on a trust basis?

cheers

andrew

---------------------------(end of broadcast)---------------------------
TIP 2: Don't 'kill -9' the postmaster

On Tue, Jul 11, 2006 at 11:21:54PM +0900, Satoshi Nagayasu wrote:
> Tom,
>
> Tom Lane wrote:
> > IOW pljava is (already) bigger than the other four PLs put
> > together.
> >
> > I'm inclined to think that pljava is best off staying as a
> > separate project.
>
> I was very confused some recent PL/Java versions can't be compiled
> because of PostgreSQL internal changes.
>
> If people think pl/java is important for PostgreSQL, pl/java should
> be included in PG core tree, and should have its regression tests.
>
> I think PL should be integrated with core tightly.

It's good to integrate things with the core as needed. What plans do
we have to integrate PL/J?

Cheers,
D
--
David Fetter <david@fetter.org> http://fetter.org/
phone: +1 415 235 3778 AIM: dfetter666
Skype: davidfetter

Remember to vote!

---------------------------(end of broadcast)---------------------------
TIP 4: Have you searched our list archives?

http://archives.postgresql.org

Tom,

> What about licensing issues? Does PL/Java work with any entirely-open-source
> JVMs? If not, what is the legal situation for distributing PG+PL/Java?

Actually, Sun has re-licensed the JRE to make it OSS-compatible (it's
now available for Debian, for example) They're doing a Java licensing
session at OSCON if you have any specific questions, or I can ping the
Java Licensing Guru directly. But even if other JRE's aren't supported,
licensing shouldn't be an obstacle.

>
> I'm also a bit concerned about size. By my count, lines of source code:
>
> plpgsql 19890
> plperl 4902
> plpython 4163
> pltcl 4498
> pljava 1.3.0 38711
>
> IOW pljava is (already) bigger than the other four PLs put together.

That is odd. Thomas?

>
> I'm inclined to think that pljava is best off staying as a separate
> project.

I disagree. One of the things I'm asked by every single tech market
analyst, after replication & clustering, is whether we have support for
procedural Java. So it's something large-scale users want. If PL/Tcl
belongs in the back end, then so does PL/Java.

--Josh Berkus

---------------------------(end of broadcast)---------------------------
TIP 6: explain analyze is your friend

Andrew Dunstan wrote:
> Thomas Hallgren wrote:
> >
> > 5. I'll need committer rights to the PL/Java part in order to maintain
> > it.
>
>
> Does our CVS setup cater for seggregated rights like this? Or would that
> be done on a trust basis?

Trust.

--
Bruce Momjian bruce@momjian.us
EnterpriseDB http://www.enterprisedb.com

+ If your life is a hard drive, Christ can be your backup. +

---------------------------(end of broadcast)---------------------------
TIP 5: don't forget to increase your free space map settings

Bruce Momjian wrote:
> Andrew Dunstan wrote:
> > Thomas Hallgren wrote:
> > >
> > > 5. I'll need committer rights to the PL/Java part in order to maintain
> > > it.
> >
> >
> > Does our CVS setup cater for seggregated rights like this? Or would that
> > be done on a trust basis?
>
> Trust.

And pgsql-committers archives ;-)

--
Alvaro Herrera http://www.CommandPrompt.com/
PostgreSQL Replication, Consulting, Custom Development, 24x7 support

---------------------------(end of broadcast)---------------------------
TIP 5: don't forget to increase your free space map settings

Josh Berkus wrote:
> Tom,
>
>> What about licensing issues? Does PL/Java work with any
>> entirely-open-source
>> JVMs? If not, what is the legal situation for distributing PG+PL/Java?
>
> Actually, Sun has re-licensed the JRE to make it OSS-compatible (it's
> now available for Debian, for example) They're doing a Java licensing
> session at OSCON if you have any specific questions, or I can ping
> the Java Licensing Guru directly. But even if other JRE's aren't
> supported, licensing shouldn't be an obstacle.
>
I don't see any license issue at all regardless. PL/Java is satisfied
with GCJ 4.0 or higher and compiling with that doesn't affect the binary
more then using gcc does. No JVM is required when using GCJ.

>>
>> I'm also a bit concerned about size. By my count, lines of source code:
>>
>> plpgsql 19890
>> plperl 4902
>> plpython 4163
>> pltcl 4498
>> pljava 1.3.0 38711
>>
>> IOW pljava is (already) bigger than the other four PLs put together.
>
> That is odd. Thomas?
>
It's not that odd really:

1. the mapping is strongly typed, i.e. each scalar type in PostgreSQL
has a set of functions that maps it to the correct primitive in Java
(int4 is a java int, double precision is a double etc.). PL/Java will
resort to string coercion only when no other option is left.
2. a type mapping is provided for *all* types. Scalar, composite,
pseudo, array types, and result sets.
3. new Java mappings can be created on the fly. Both for scalar and
composite types.
4. you can create new scalar types in PostgreSQL that uses IO functions
written in Java.
5. the Java code contains it's own API documentation (standard java-doc
comments on classes and methods).
6. the code is written to conform to standard interfaces such as the
JDBC interfaces (from a #lines perspective, perhaps not always the most
optimal way of doing it but it does bring a bunch of other advantages).
7. extensive error handling is included that allow try/catch semantics
when checkpoints are used.
8. extreme measures has been taken to ensure that the backend is never
exposed to more then one thread at a time.
....
(from the top of my head, there are probably more reasons)

IMHO, this is yet another reason to actually include it in core. I'm not
an expert on the other PL's but my guess is that PL/Java is far more
sensitive to API changes in the backend core.

Regards,
Thomas Hallgren





---------------------------(end of broadcast)---------------------------
TIP 5: don't forget to increase your free space map settings