Three weeks left until feature freeze

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(at)momjian(dot)us
EnterpriseDB http://www.enterprisedb.com

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

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(at)momjian(dot)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
>

Thomas Hallgren <thomas(at)tada(dot)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

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(at)nttdata(dot)co(dot)jp>
Phone: +81-3-3523-8122

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

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

> -----Original Message-----
> From: pgsql-hackers-owner(at)postgresql(dot)org
> [mailto:pgsql-hackers-owner(at)postgresql(dot)org] On Behalf Of
> Andrew Dunstan
> Sent: 11 July 2006 15:27
> To: Thomas Hallgren
> Cc: pgsql-hackers(at)postgresql(dot)org
> Subject: Re: [HACKERS] Three weeks left until feature freeze
>
> 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?

No, I don't believe you can do this with CVS at all. We'd need something
like SVN/WebDAV to be able to grant write access just to specific parts
of the tree to different people.

Regards, Dave.

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(at)fetter(dot)org> http://fetter.org/
phone: +1 415 235 3778 AIM: dfetter666
Skype: davidfetter

Remember to vote!

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(at)momjian(dot)us
EnterpriseDB http://www.enterprisedb.com

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

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

Josh Berkus wrote:

> >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.

We've discussed this before, regarding PL/php IIRC. The conclusions the
last time around, as far as I remember, was that we wanted the PLs to be
in the same CVS repo, but able to be compiled separately from the whole
source tree. So we could sort of rip PL/Perl et al from the actual
backend code, leaving only enough infrastructure to be able to build
them easily (PGXS plus a bunch of stuff, I imagine). PL modules would
follow the backend branches so that there would be no need for pesky
#ifdef PGSQL_VERSION_THIS_OR_THAT stuff; but they would actually be
separate.

The main motivation was that when somebody wants to change an interface
in the backend that's used by PLs, it's useful to change all of them at
the same time instead of waiting until release time comes and the things
does not compile anymore and nobody remembers when or where they were
broken.

I think this would also allow PL/R to be included as well despite the
license, because while it would be in the same repo and editable
together with the backend, it would continue to be a separate project
and thus not contaminate the backend with GPL stuff.

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

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

> > Does our CVS setup cater for seggregated rights like this? Or
> > would that
> > be done on a trust basis?
>
> No, I don't believe you can do this with CVS at all. We'd need something
> like SVN/WebDAV to be able to grant write access just to specific parts
> of the tree to different people.

It is possible using CVS, by carefully managing file system permissions
and assigning different permissions to the OS users of the different
committers. I guess it's also possible using commit scripts... but I
don't think it worths the effort as long as there is a regular backup of
the CVS tree...

Cheers,
Csaba.

David,

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

None, if the PL/J team doesn't speak up. So far I have yet to see a
request for PL/J or even a release notice.

--Josh

Andrew Dunstan <andrew(at)dunslane(dot)net> writes:
> 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?

No, and yes. However, I don't have a problem with giving Thomas
committer access --- I'm just dubious about having PL/Java in the
core distro at all.

regards, tom lane

* Josh Berkus (josh(at)agliodbs(dot)com) wrote:
> 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.

Uhh.. Let's not go overboard here on exactly what Debian has done with
Sun's JVM. Technically, Sun's JVM is *not* part of Debian. The license
is (and even this is hotly debated...) acceptable enough for Debian's
ftp-masters to allow the Sun JVM to be distributed off Debian servers as
part of the 'non-free' archive. This *certainly* doesn't make it
OSS-compatible by any stretch (it isn't) and it's not acceptable for
inclusion in Debian proper.

I'm actually rather upset to see Sun making such blatently incorrect
statements. Josh, I truely hope that you weren't actually involved in
the Sun JVM-in-Debian work and so were unaware of the very important
distinction between "Distributed by Debian" and "in Debian/main".

Thanks,

Stephen

Snowman,

> Uhh.. Let's not go overboard here on exactly what Debian has done with
> Sun's JVM. Technically, Sun's JVM is *not* part of Debian. The license
> is (and even this is hotly debated...) acceptable enough for Debian's
> ftp-masters to allow the Sun JVM to be distributed off Debian servers as
> part of the 'non-free' archive. This *certainly* doesn't make it
> OSS-compatible by any stretch (it isn't) and it's not acceptable for
> inclusion in Debian proper.

I think I can tell which side of the debate you were on.

> I'm actually rather upset to see Sun making such blatently incorrect
> statements. Josh, I truely hope that you weren't actually involved in
> the Sun JVM-in-Debian work and so were unaware of the very important
> distinction between "Distributed by Debian" and "in Debian/main".

Keep your pants on, geez. I'm actually rather appalled that you could
get so unjustifiably bent out of shape at me *after* we met. Goes to
show you that not everything is improved by personal acquaintance.

Let's get some stuff clear:

1) I do not speak for Sun execept on specific occasions arranged by Sun
PR. Not ever.

2) If you re-read my message, it says:
... (it's now available for Debian, for example) ...
not ANYTHING about main or distributed or non-free or whatever.

So, I think you owe me an apology.

--Josh

* Josh Berkus (josh(at)agliodbs(dot)com) wrote:
> I think I can tell which side of the debate you were on.

The debate was regarding Sun's JVM being distributed by Debian at all...
There wasn't any debate regarding it's free vs. non-free status so far
as I'm aware. I don't believe there was ever any intention to include
Sun's JVM in Debian/main with it's current license. If you meant
something other than free/non-free by 'OSS-compatible' then you might
have wanted to make that clear since generally that refers to the OSI
Open Source Definition (and/or the DFSG, they're pretty similar tho).

I've not heard 'OSS-compatible' used to refer to 'can run under Linux'
or 'can run on Debian' before. That'd include things like Oracle.

> >I'm actually rather upset to see Sun making such blatently incorrect
> >statements. Josh, I truely hope that you weren't actually involved in
> >the Sun JVM-in-Debian work and so were unaware of the very important
> >distinction between "Distributed by Debian" and "in Debian/main".
>
> Keep your pants on, geez. I'm actually rather appalled that you could
> get so unjustifiably bent out of shape at me *after* we met. Goes to
> show you that not everything is improved by personal acquaintance.

Actually, I felt that I pretty clearly gave you the benefit of the
doubt... For many people it's an unfortunate and pretty likely
assumption based on things written on /., etc. It wasn't an attack on
you but rather the frustrated realization that the concerns of many in
Debian regarding Sun's JVM inclusion in non-free may have been justified.

> 2) If you re-read my message, it says:
> ... (it's now available for Debian, for example) ...
> not ANYTHING about main or distributed or non-free or whatever.

If you hadn't intended to refer to Debian's inclusion of the Sun JVM in
non-free then I'm rather confused since there has been a trivial-to-use
package available in non-free for a long time to download the Sun JVM
from Sun and create debs to install it with. So, it's been available
*for* Debian for a long time, but was only recently put into non-free..
It was also available prior to that, though a pain to install..

You seemed to use the recent change in status of Sun's JVM (at least in
part with regard to Debian...) as justification of your statement that
it's OSS-compatible..

That's exactly the misrepresentation which I was addressing.

> So, I think you owe me an apology.

I apologize for being harsher than I should have.

Thanks,

Stephen

Stephen,

> You seemed to use the recent change in status of Sun's JVM (at least in
> part with regard to Debian...) as justification of your statement that
> it's OSS-compatible..

Are you going to be at OSCON? Sun's hosting a BOF to discuss exactly
this issue.

--Josh

On Tuesday 11 July 2006 09:59, Tom Lane wrote:
> Andrew Dunstan <andrew(at)dunslane(dot)net> writes:
> > 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?
>
> No, and yes. However, I don't have a problem with giving Thomas
> committer access --- I'm just dubious about having PL/Java in the
> core distro at all.

Personally I would like to see in core, but it is not from a technical
perspective. It is purely from a marketing perspective (doubt that carries
much weight here ;)).

Having pl/Java helps PostgreSQL in the minds of all those tie wearing decision
making freaks... and before you say it, No. I do not wear a tie.

Sincerely,

Joshua D. Drake

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

--
=== The PostgreSQL Company: Command Prompt, Inc. ===
Sales/Support: +1.503.667.4564 || 24x7/Emergency: +1.800.492.2240
Providing the most comprehensive PostgreSQL solutions since 1997
http://www.commandprompt.com/

Joshua D. Drake wrote:

>... and before you say it, No. I do not wear a tie.
>
>
>

Maybe you need to ... ;-)

cheers

andrew

On Tuesday 11 July 2006 13:49, Andrew Dunstan wrote:
> Joshua D. Drake wrote:
> >... and before you say it, No. I do not wear a tie.
>
> Maybe you need to ... ;-)
>

/me bows before the gods who thoust commit.

>
> cheers
>
> andrew

--
=== The PostgreSQL Company: Command Prompt, Inc. ===
Sales/Support: +1.503.667.4564 || 24x7/Emergency: +1.800.492.2240
Providing the most comprehensive PostgreSQL solutions since 1997
http://www.commandprompt.com/

Ühel kenal päeval, T, 2006-07-11 kell 17:34, kirjutas Thomas Hallgren:
> Josh Berkus wrote:
> > Tom,
> >

> >> 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.

Maybe this functionality could be lifted out of PL/Java and made
available to all PL-s ?

At least at some API level.

--
----------------
Hannu Krosing
Database Architect
Skype Technologies OÜ
Akadeemia tee 21 F, Tallinn, 12618, Estonia

Skype me: callto:hkrosing
Get Skype for free: http://www.skype.com

On Tue, 11 Jul 2006, Josh Berkus wrote:

> 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.

There should be a Procedural Language section on pgfoundry for all of the
PLs, IMHO, and a README in contrib within core that points to it
(README.procedural_languages, if nothing else) ...

----
Marc G. Fournier Hub.Org Networking Services (http://www.hub.org)
Email . scrappy(at)hub(dot)org MSN . scrappy(at)hub(dot)org
Yahoo . yscrappy Skype: hub.org ICQ . 7615664

Hi Hannu,

Hannu Krosing wrote:
> Maybe this functionality could be lifted out of PL/Java and made
> available to all PL-s ?
>
> At least at some API level.
>
>
I think that what could be shared are the ideas and the semantics. The
API's that the backend currently expose will give you what's needed to
do the specialized implementations.

The actual PL mappings are all different because their respective
"executor" is different. Some languages are typed, others are not. Some
languages support classes and objects, others don't. Other, more
esoteric details like the use of a garbage collector or traditional
alloc/free semantics also affects the actual implementation.

I'm afraid there's not much in the PL/Java type system that could be
generalized and shared. Perhaps if we had other languages with very
similar capabilities (like C# for instance) but even then I have some
doubts. The good news in my opinion is that if PL/Java would make it to
the core it could make a good reference implementation for other equally
advanced language mappings.

Regards,
Thomas Hallgren

> I'm afraid there's not much in the PL/Java type system that could be
> generalized and shared. Perhaps if we had other languages with very
> similar capabilities (like C# for instance) but even then I have some
> doubts. The good news in my opinion is that if PL/Java would make it to
> the core it could make a good reference implementation for other equally
> advanced language mappings.

What is the actual concern with having PL/Java in core, versus say PL/Perl?

Sincerely,

Joshua D. Drake

>
> Regards,
> Thomas Hallgren
>
>
>
>
>
>
> ---------------------------(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

--
=== The PostgreSQL Company: Command Prompt, Inc. ===
Sales/Support: +1.503.667.4564 || 24x7/Emergency: +1.800.492.2240
Providing the most comprehensive PostgreSQL solutions since 1997
http://www.commandprompt.com/

> No, I don't believe you can do this with CVS at all. We'd need something
> like SVN/WebDAV to be able to grant write access just to specific parts
> of the tree to different people.

You just use an on-commit script like cvsacl.

Marc G. Fournier wrote:
> On Tue, 11 Jul 2006, Josh Berkus wrote:
>
> >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.
>
> There should be a Procedural Language section on pgfoundry for all of the
> PLs, IMHO, and a README in contrib within core that points to it
> (README.procedural_languages, if nothing else) ...

This is not a smart idea, because it will mean API changes in the
backend cannot fix the PLs right away (and also because it's harder to
track each core branch, something which having the actual language in
the same repo makes trivial AFAIK). I don't understand why you keep
proposing this after having the idea shot down over and over.

--
Alvaro Herrera http://www.CommandPrompt.com/
The PostgreSQL Company - Command Prompt, Inc.

> There should be a Procedural Language section on pgfoundry for all of the
> PLs, IMHO, and a README in contrib within core that points to it
> (README.procedural_languages, if nothing else) ...

I thought that the general consensus was that only plpgsql ought to be in
core, the rest should be independent projects.

It would be nice to have an easy way to retrieve and install the desired PL's
but that's more of a packaging issue.

--

Med venlig hilsen
Kaare Rasmussen, Jasonic

Jasonic Telefon: +45 3816 2582
Nordre Fasanvej 12
2000 Frederiksberg Email: kaare(at)jasonic(dot)dk

Absolutely PL/J should be considered in the same light as PL/Java.

Consider this a request for PL/J to be included in the core.

Dave
On 11-Jul-06, at 12:50 PM, Josh Berkus wrote:

> David,
>
>> It's good to integrate things with the core as needed. What plans do
>> we have to integrate PL/J?
>
> None, if the PL/J team doesn't speak up. So far I have yet to see
> a request for PL/J or even a release notice.
>
> --Josh
>
> ---------------------------(end of
> broadcast)---------------------------
> TIP 5: don't forget to increase your free space map settings
>

Marc G. Fournier wrote:
>
> There should be a Procedural Language section on pgfoundry for all of
> the PLs, IMHO, and a README in contrib within core that points to it
> (README.procedural_languages, if nothing else) ...
>

This was a bad idea last time it was proposed and is still a bad idea
for the same reasons that caused it to be rejected then.

cheers

andrew

Kaare Rasmussen wrote:
>> There should be a Procedural Language section on pgfoundry for all of the
>> PLs, IMHO, and a README in contrib within core that points to it
>> (README.procedural_languages, if nothing else) ...
>>
>
> I thought that the general consensus was that only plpgsql ought to be in
> core, the rest should be independent projects.
>
>

Quite the contrary, if anything.

cheers

andrew

Hi Dave,
Sorry I missed you at the Summit. I would've liked to discuss PL/J
versus PL/Java with you.

What is the status of PL/J? I haven't seen much activity there over the
last 10 months. Does it run on Windows yet? Are you planning a first
release anytime soon? Do you have any active users? Does the project
still have over 40 dependencies to other components? The last time I
looked (August last year) a beta-0.1.1 was planned. I didn't manage to
built it and it didn't seem anywhere close production readiness.

Perhaps it's no surprise that I disagree when you say PL/J could be
considered in the same light as PL/Java. Then again, I'm fairly biased ;-)

Regards,
Thomas Hallgren

Dave Cramer wrote:
> Absolutely PL/J should be considered in the same light as PL/Java.
>
> Consider this a request for PL/J to be included in the core.
>
> Dave
> On 11-Jul-06, at 12:50 PM, Josh Berkus wrote:
>
>> David,
>>
>>> It's good to integrate things with the core as needed. What plans do
>>> we have to integrate PL/J?
>>
>> None, if the PL/J team doesn't speak up. So far I have yet to see a
>> request for PL/J or even a release notice.
>>
>> --Josh
>>
>> ---------------------------(end of broadcast)---------------------------
>> TIP 5: don't forget to increase your free space map settings
>>
>

Am Dienstag, 11. Juli 2006 17:40 schrieb Alvaro Herrera:
> We've discussed this before, regarding PL/php IIRC. The conclusions the
> last time around, as far as I remember, was that we wanted the PLs to be
> in the same CVS repo, but able to be compiled separately from the whole
> source tree.

That was precisely what I recall. But if we make them separate CVS modules,
they would not have the same branch structure, or would they?

--
Peter Eisentraut
http://developer.postgresql.org/~petere/

Ühel kenal päeval, K, 2006-07-12 kell 09:49, kirjutas Kaare Rasmussen:
> > There should be a Procedural Language section on pgfoundry for all of the
> > PLs, IMHO, and a README in contrib within core that points to it
> > (README.procedural_languages, if nothing else) ...
>
> I thought that the general consensus was that only plpgsql ought to be in
> core, the rest should be independent projects.

That would be doable if we had a stable language API.

As i understand it, we still dont. And even more - most of the changes
to API come frome the needs of those (new) languages

> It would be nice to have an easy way to retrieve and install the desired PL's
> but that's more of a packaging issue.
>
--
----------------
Hannu Krosing
Database Architect
Skype Technologies OÜ
Akadeemia tee 21 F, Tallinn, 12618, Estonia

Skype me: callto:hkrosing
Get Skype for free: http://www.skype.com

Hannu Krosing wrote:
> Ühel kenal päeval, K, 2006-07-12 kell 09:49, kirjutas Kaare Rasmussen:
>
>>> There should be a Procedural Language section on pgfoundry for all of the
>>> PLs, IMHO, and a README in contrib within core that points to it
>>> (README.procedural_languages, if nothing else) ...
>>>
>> I thought that the general consensus was that only plpgsql ought to be in
>> core, the rest should be independent projects.
>>
>
> That would be doable if we had a stable language API.
>
> As i understand it, we still dont. And even more - most of the changes
> to API come frome the needs of those (new) languages
>
>

There is in effect no API at all, other than what is available to all
backend modules. If someone wants to create an API which will be both
sufficiently stable and sufficiently complete to meet the needs of the
various PLs (especially, as Hannu rightly observes, any new PLs that
come along) then we can revisit this question. Until then I suggest
that it is at best premature. I am not even sure such a thing is
actually possible.

Also there is this: speaking as someone who actually does some work in
this area, I very much appreciate having the eagle eyes of people like
Tom, Neil and Joe on what's going on, and keeping things on the straight
and narrow. I at least would feel lots less comfortable about
maintaining things without such help.

The Postgres hacker community is small. I am not sure there is an
adequate pool of people who will maintain the momentum of each
sub-project that we might choose to orphan. If we had thousands of eager
code cutters it might be different, but we don't, really.

cheers

andrew

On Wednesday 12 July 2006 04:15, Dave Cramer wrote:
> Absolutely PL/J should be considered in the same light as PL/Java.
>
> Consider this a request for PL/J to be included in the core.

Frankly I don't care which one is used, as long as the one (and ONLY one) that
is included is the most mature and stable.

Sincerely,

Joshua D. Drake

>
> Dave
>
> On 11-Jul-06, at 12:50 PM, Josh Berkus wrote:
> > David,
> >
> >> It's good to integrate things with the core as needed. What plans do
> >> we have to integrate PL/J?
> >
> > None, if the PL/J team doesn't speak up. So far I have yet to see
> > a request for PL/J or even a release notice.
> >
> > --Josh
> >
> > ---------------------------(end of
> > broadcast)---------------------------
> > TIP 5: don't forget to increase your free space map settings
>
> ---------------------------(end of broadcast)---------------------------
> TIP 6: explain analyze is your friend

--
=== The PostgreSQL Company: Command Prompt, Inc. ===
Sales/Support: +1.503.667.4564 || 24x7/Emergency: +1.800.492.2240
Providing the most comprehensive PostgreSQL solutions since 1997
http://www.commandprompt.com/

On Wed, Jul 12, 2006 at 07:29:52AM -0700, Joshua D. Drake wrote:
> On Wednesday 12 July 2006 04:15, Dave Cramer wrote:
> > Absolutely PL/J should be considered in the same light as PL/Java.
> >
> > Consider this a request for PL/J to be included in the core.
>
> Frankly I don't care which one is used, as long as the one (and ONLY one) that
> is included is the most mature and stable.

Are they mutually exclusive? I can imagine, at least for development
purposes, that someone might want to install both.

Cheers,
D
>
> Sincerely,
>
> Joshua D. Drake
>
> >
> > Dave
> >
> > On 11-Jul-06, at 12:50 PM, Josh Berkus wrote:
> > > David,
> > >
> > >> It's good to integrate things with the core as needed. What plans do
> > >> we have to integrate PL/J?
> > >
> > > None, if the PL/J team doesn't speak up. So far I have yet to see
> > > a request for PL/J or even a release notice.
> > >
> > > --Josh
> > >
> > > ---------------------------(end of
> > > broadcast)---------------------------
> > > TIP 5: don't forget to increase your free space map settings
> >
> > ---------------------------(end of broadcast)---------------------------
> > TIP 6: explain analyze is your friend
>
> --
> === The PostgreSQL Company: Command Prompt, Inc. ===
> Sales/Support: +1.503.667.4564 || 24x7/Emergency: +1.800.492.2240
> Providing the most comprehensive PostgreSQL solutions since 1997
> http://www.commandprompt.com/
>

--
David Fetter <david(at)fetter(dot)org> http://fetter.org/
phone: +1 415 235 3778 AIM: dfetter666
Skype: davidfetter

Remember to vote!

On 7/12/06, Thomas Hallgren <thomas(at)tada(dot)se> wrote:
> it didn't seem anywhere close production readiness.
>
> Perhaps it's no surprise that I disagree when you say PL/J could be
> considered in the same light as PL/Java.

Having used both systems, I have to agree with Thomas; PL/Java is far
ahead of PL/J in terms of production readiness. Rather than argue the
differences between the architectures... I think it should be looked
at on a pro/con basis.

Many people have asked for procedural Java and generally pass over
PostgreSQL because they don't know about PL/Java or PL/J. In my
opinion, having a Java PL included in the core would be ideal.

PL/Java seems to be the only Java PL under consistent development and
maintenance, so I don't see it as something that would fall on the
shoulders of all other maintainers.

Just my 2 cents :)

--
Jonah H. Harris, Software Architect | phone: 732.331.1300
EnterpriseDB Corporation | fax: 732.331.1301
33 Wood Ave S, 2nd Floor | jharris(at)enterprisedb(dot)com
Iselin, New Jersey 08830 | http://www.enterprisedb.com/

On 7/12/06, David Fetter <david(at)fetter(dot)org> wrote:
> Are they mutually exclusive? I can imagine, at least for development
> purposes, that someone might want to install both.

I believe both can be installed and running at the same time. I don't
really think anyone would want to run both, but that's just my
opinion.

--
Jonah H. Harris, Software Architect | phone: 732.331.1300
EnterpriseDB Corporation | fax: 732.331.1301
33 Wood Ave S, 2nd Floor | jharris(at)enterprisedb(dot)com
Iselin, New Jersey 08830 | http://www.enterprisedb.com/

Andrew Dunstan wrote:
> There is in effect no API at all, other than what is available to all
> backend modules. If someone wants to create an API which will be both
> sufficiently stable and sufficiently complete to meet the needs of the
> various PLs (especially, as Hannu rightly observes, any new PLs that
> come along) then we can revisit this question. Until then I suggest
> that it is at best premature. I am not even sure such a thing is
> actually possible.
>
I concur with this. The needs for a module like PL/Java is very different then the needs of
PL/Perl so let's get some more PL's in before we do a refactoring effort to create common
API's. Personally, I'm not sure what would be included. The call handler API's together with
the SPI API's are in essence what you need. The rest is fairly specialized anyway.

> Also there is this: speaking as someone who actually does some work in
> this area, I very much appreciate having the eagle eyes of people like
> Tom, Neil and Joe on what's going on, and keeping things on the straight
> and narrow. I at least would feel lots less comfortable about
> maintaining things without such help.
>
This is partly why I'd like to get PL/Java included. Not that I expect any of them to devote
resources to PL/Java but I think that they, from time to time, will visit the code. If not
for anything else then to see why some other change caused build failures. It's always
easier to have discussions around code that you know they all have on disk.

> The Postgres hacker community is small. I am not sure there is an
> adequate pool of people who will maintain the momentum of each
> sub-project that we might choose to orphan. If we had thousands of eager
> code cutters it might be different, but we don't, really.
>
As the project grows for various reasons, the number of hackers in the community will grow
as well. PL/Java for instance, does not come without resources :-)

Regards,
Thomas Hallgren

> I concur with this. The needs for a module like PL/Java is very different
> then the needs of PL/Perl so let's get some more PL's in before we do a
> refactoring effort to create common API's. Personally, I'm not sure what
> would be included. The call handler API's together with the SPI API's are
> in essence what you need. The rest is fairly specialized anyway.

Well I know it isn't an API per say, but one interesting tid bit as an example
is that PLphp does not need the PostgreSQL source to compile. It only needs
pgxs and the relevant headers etc...

Perhaps that is one way to go... All PLs use pgxs?

> As the project grows for various reasons, the number of hackers in the
> community will grow as well. PL/Java for instance, does not come without
> resources :-)

We have already grown for hackers quite a bit this year as they mature I think
we will see even more patch review eyes and such... Soon.

Sincerely,

Joshua D. Drake

>
> Regards,
> Thomas Hallgren
>
>
> ---------------------------(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

--
=== The PostgreSQL Company: Command Prompt, Inc. ===
Sales/Support: +1.503.667.4564 || 24x7/Emergency: +1.800.492.2240
Providing the most comprehensive PostgreSQL solutions since 1997
http://www.commandprompt.com/

On Wed, Jul 12, 2006 at 10:14:53AM -0400, Andrew Dunstan wrote:
> Hannu Krosing wrote:
> >Ühel kenal päeval, K, 2006-07-12 kell 09:49, kirjutas Kaare Rasmussen:
> >
> >>>There should be a Procedural Language section on pgfoundry for all of the
> >>>PLs, IMHO, and a README in contrib within core that points to it
> >>>(README.procedural_languages, if nothing else) ...
> >>>
> >>I thought that the general consensus was that only plpgsql ought to be in
> >>core, the rest should be independent projects.
> >>
> >
> >That would be doable if we had a stable language API.
> >
> >As i understand it, we still dont. And even more - most of the changes
> >to API come frome the needs of those (new) languages
> >
> >
>
> There is in effect no API at all, other than what is available to all
> backend modules. If someone wants to create an API which will be both
> sufficiently stable and sufficiently complete to meet the needs of the
> various PLs (especially, as Hannu rightly observes, any new PLs that
> come along) then we can revisit this question. Until then I suggest
> that it is at best premature. I am not even sure such a thing is
> actually possible.
>
> Also there is this: speaking as someone who actually does some work in
> this area, I very much appreciate having the eagle eyes of people like
> Tom, Neil and Joe on what's going on, and keeping things on the straight
> and narrow. I at least would feel lots less comfortable about
> maintaining things without such help.

If I've caught the right threads... Informix IUS and Illustra had a language
manager module which facilitated function resolution and argument marshalling
ala SQL and then made the calls to each language in the same API/function
call format. Usually I do not like added layers, however, this layer could
and should be used to deal with function resolution, type coercion, domains,
etc, which is the SQL side. The language itself would have predefined ways
of getting arguments and returning data. I'm not sure if this approach
would work with the bonus extras on plpgsql, but it should.

If anyone wants to pursue this area, please include me on the discussion
and I can try to provide information regarding the other implementation.

--elein

>
> The Postgres hacker community is small. I am not sure there is an
> adequate pool of people who will maintain the momentum of each
> sub-project that we might choose to orphan. If we had thousands of eager
> code cutters it might be different, but we don't, really.
>
> cheers
>
> andrew
>
>
>
> ---------------------------(end of broadcast)---------------------------
> TIP 1: if posting/reading through Usenet, please send an appropriate
> subscribe-nomail command to majordomo(at)postgresql(dot)org so that your
> message can get through to the mailing list cleanly
>

Joshua D. Drake wrote:
>
> Well I know it isn't an API per say, but one interesting tid bit as an example
> is that PLphp does not need the PostgreSQL source to compile. It only needs
> pgxs and the relevant headers etc...
>
> Perhaps that is one way to go... All PLs use pgxs?
>
>
PL/Java does. No source needed. So yes, there's already a fairly good
API that assists in the module build process. It does however still
include all header files needed by the backend and thus, leaves the
backend wide open (in a matter of speech). If a refactoring effort was
to start later on, that would be a good place to start. I.e. divide
headers into the ones available for external modules and the ones for
internal backend use only.

Regards,
Thomas Hallgren

"Jonah H. Harris" <jonah(dot)harris(at)gmail(dot)com> writes:
> On 7/12/06, David Fetter <david(at)fetter(dot)org> wrote:
>> Are they mutually exclusive? I can imagine, at least for development
>> purposes, that someone might want to install both.

> I believe both can be installed and running at the same time. I don't
> really think anyone would want to run both, but that's just my
> opinion.

On what grounds do you not think that? PL/J uses an external JVM,
PL/Java one that is running in the backend process. (Or maybe it was
the other way 'round, I'm too tired to remember tonight.) That's a
really fundamental difference that makes them suited for very different
applications; not to mention the resulting different licensing scenarios.

The points that have been made in this thread about PL/J not being
actively maintained are important, but other than that objection,
I can see no reason that PL/J wouldn't have an equal claim to inclusion
in core. Perhaps more, because it gives us an extra layer of insulation
from JVM licensing questions.

regards, tom lane

On 12-Jul-06, at 10:44 PM, Tom Lane wrote:

> "Jonah H. Harris" <jonah(dot)harris(at)gmail(dot)com> writes:
>> On 7/12/06, David Fetter <david(at)fetter(dot)org> wrote:
>>> Are they mutually exclusive? I can imagine, at least for
>>> development
>>> purposes, that someone might want to install both.
>
>> I believe both can be installed and running at the same time. I
>> don't
>> really think anyone would want to run both, but that's just my
>> opinion.
>
> On what grounds do you not think that? PL/J uses an external JVM,
> PL/Java one that is running in the backend process. (Or maybe it was
> the other way 'round, I'm too tired to remember tonight.) That's a
> really fundamental difference that makes them suited for very
> different
> applications; not to mention the resulting different licensing
> scenarios.
No, this is correct.
>
> The points that have been made in this thread about PL/J not being
> actively maintained are important, but other than that objection,

I expect to see a new release shortly.
> I can see no reason that PL/J wouldn't have an equal claim to
> inclusion
> in core. Perhaps more, because it gives us an extra layer of
> insulation
> from JVM licensing questions.
>
> regards, tom lane
>

Dave Cramer wrote:
>
> I expect to see a new release shortly.
Dave, I tried to obtain the source but whenever I try I get:

[thhal]$ cvs -d
:pserver:anonymous(at)cvs(dot)plj(dot)codehaus(dot)org:/home/projects/plj/scm login
Logging in to
:pserver:anonymous(at)cvs(dot)plj(dot)codehaus(dot)org:2401/home/projects/plj/scm
CVS password:
/home/projects/plj/scm: no such repository

I can browse the source using the web interface though. Judging from
that, there's been no CVS activity since I last tried, i.e. august last
year. Is the source being maintained somewhere else? How do I obtain the
latest CVS? Judging from your statement a lot must have happened that
would be interesting to look at.

Regards,
Thomas Hallgren

Tom Lane wrote:
> ... equal claim to inclusion
> in core. Perhaps more, because it gives us an extra layer of insulation
> from JVM licensing questions.
>
Tom,
Why to you persist talking about licensing issues with PL/Java? There are none. PL/Java
builds and runs just fine with gcj and the above statement is completely false.

Dave,
What JVM requirements does PL/J currently have? What license implications are imposed by the
components that it depends upon?

Regards,
Thomas Hallgren

Thomas Hallgren wrote:
> Tom Lane wrote:
>> ... equal claim to inclusion
>> in core. Perhaps more, because it gives us an extra layer of insulation
>> from JVM licensing questions.
>>
> Tom,
> Why to you persist talking about licensing issues with PL/Java? There
> are none. PL/Java builds and runs just fine with gcj and the above
> statement is completely false.

Just to further this with actual documentation :)

1.1 What license is used for libgcj?

libgcj is distributed under the GPL, with the 'libgcc exception'.
This means that linking with libgcj does not by itself cause your
program to fall under the GPL. See LIBGCJ_LICENSE in the source tree for
more details.

Sincerely,

Joshua D. Drake

>
> Dave,
> What JVM requirements does PL/J currently have? What license
> implications are imposed by the components that it depends upon?
>
> Regards,
> Thomas Hallgren
>

--

=== The PostgreSQL Company: Command Prompt, Inc. ===
Sales/Support: +1.503.667.4564 || 24x7/Emergency: +1.800.492.2240
Providing the most comprehensive PostgreSQL solutions since 1997
http://www.commandprompt.com/

Thomas Hallgren <thomas(at)tada(dot)se> writes:
> Why to you persist talking about licensing issues with PL/Java? There are none. PL/Java
> builds and runs just fine with gcj and the above statement is completely false.

Um ... if you use it with gcj, there may or may not be any licensing
problems (please recall we are trying to be a BSD-only project, not a
BSD-and-LGPL project), but what of people who use some other JVM?
It's not like gcj works for everyone yet.

regards, tom lane

Tom Lane wrote:
> Thomas Hallgren <thomas(at)tada(dot)se> writes:
>
>> Why to you persist talking about licensing issues with PL/Java? There are none. PL/Java
>> builds and runs just fine with gcj and the above statement is completely false.
>>
>
> Um ... if you use it with gcj, there may or may not be any licensing
> problems (please recall we are trying to be a BSD-only project, not a
> BSD-and-LGPL project),
You have no problems using gcc, gnu-make, etc. What's the difference?

> but what of people who use some other JVM?
> It's not like gcj works for everyone yet.
>
>
What of them? If they decide to use another JVM, well, then let them. I
don't see where that becomes a licensing problem from PostgreSQL.

Regards,
Thomas Hallgren

Thomas,

I'm starting to have second thoughts about this suggestion. I was
enthusiastic about it at the summit, but I was unaware of the sheer size
of PL/Java. 38,000 lines of code is 8% of the total size of Postgresql
... for *one* PL.

Dave Cramer acquainted me with some of the difficulties of doing a Java
PL today, and I understand why it needs to be that large. However,
38,000 lines of code -- much of it in a non-C language -- presents a
possible debugging/maintenance major headache, especially if you someday
left the project for some reason.

Maybe we do need to look at a plug-in build tool, instead.

> Perhaps it's no surprise that I disagree when you say PL/J could be
> considered in the same light as PL/Java. Then again, I'm fairly biased ;-)

This attitude does you no credit, Thomas.

--Josh Berkus

Tom,

Perhaps more, because it gives us an extra layer of insulation
> from JVM licensing questions.

I really don't see licensing issues as being relevant. Your other
concern certainly is, though.

--Josh

Josh Berkus wrote:
>
>> Perhaps it's no surprise that I disagree when you say PL/J could be
>> considered in the same light as PL/Java. Then again, I'm fairly
>> biased ;-)
>
> This attitude does you no credit, Thomas.
>
My diplomatic skills are somewhat limited :-) I might be blunt at times.
I'm sure there are other more subtle ways to get the message through.
I'm trying to be honest and up-front. IMO, that should count for something.

Regards,
Thomas Hallgren

Thomas Hallgren wrote:
> Tom Lane wrote:
>> Thomas Hallgren <thomas(at)tada(dot)se> writes:
>>
>>> Why to you persist talking about licensing issues with PL/Java? There
>>> are none. PL/Java builds and runs just fine with gcj and the above
>>> statement is completely false.
>>>
>>
>> Um ... if you use it with gcj, there may or may not be any licensing
>> problems (please recall we are trying to be a BSD-only project, not a
>> BSD-and-LGPL project),
> You have no problems using gcc, gnu-make, etc. What's the difference?

Well there is a couple of literal differences.

gcc, gnu-make are irrelevant. What is relevant is libc which is LGPL.

Gcj IS GPL, not LGPL :( it just has an exception clause

Keep in mind that that there are all kinds of oddities when mixing
licenses. Is Sun's JVM GPL compatible? If not, the plJava can't use it.

What happens when the FSF inevitably removes the license clause and
makes it pure GPL?

Now all of this being said, I doubt there is actually an issue here because:

It doesn't HAVE TO BE BUILT, it is not a derivative product.

It doesn't ship with the JVM which means it is up to the user to break
the license not the PostgreSQL project...

However that last one is bad mojo :(

Sincerely,

Joshua D. Drake

>
>> but what of people who use some other JVM?
>> It's not like gcj works for everyone yet.
>>
>>
> What of them? If they decide to use another JVM, well, then let them. I
> don't see where that becomes a licensing problem from PostgreSQL.
>
> Regards,
> Thomas Hallgren
>

--

=== The PostgreSQL Company: Command Prompt, Inc. ===
Sales/Support: +1.503.667.4564 || 24x7/Emergency: +1.800.492.2240
Providing the most comprehensive PostgreSQL solutions since 1997
http://www.commandprompt.com/

Josh Berkus wrote:
> Thomas,
>
> I'm starting to have second thoughts about this suggestion. I was
> enthusiastic about it at the summit, but I was unaware of the sheer size
> of PL/Java. 38,000 lines of code is 8% of the total size of Postgresql
> ... for *one* PL.
>
> Dave Cramer acquainted me with some of the difficulties of doing a Java
> PL today, and I understand why it needs to be that large. However,
> 38,000 lines of code -- much of it in a non-C language -- presents a
> possible debugging/maintenance major headache, especially if you someday
> left the project for some reason.
>
OK. You're the one that suggested this submission attempt. There's not much point in
pursuing it if you have second thoughts.

> Maybe we do need to look at a plug-in build tool, instead.
>
Right, something that would allow PL/Java to participate in a build farm. That would be cool
and also resolve a some of the issues.

Regards,
Thomas Hallgren

Joshua D. Drake wrote:
> What happens when the FSF inevitably removes the license clause and
> makes it pure GPL?
>
I'm sorry but I don't follow. You're saying that it's inevitable that
FSF will remove the 'libgcc' exception from libgcj? Why on earth would
they do that? My guess is that it will go the other way (i.e. LGPL).
What's the logic in having different licenses on libg++ and libgcj?

> Now all of this being said, I doubt there is actually an issue here
> because:
>
> It doesn't HAVE TO BE BUILT, it is not a derivative product.
>
Well, assume that FSF indeed did remove the exception. It would take me
30 minutes or so to create a substitute BSD licensed dummy JNI library
with associated headers that would allow PL/Java to be built without any
external modules at all. It's then completely up to the user what he/she
wants to slot in as a replacement.

Regards,
Thomas Hallgren

> Well, assume that FSF indeed did remove the exception. It would take me
> 30 minutes or so to create a substitute BSD licensed dummy JNI library
> with associated headers that would allow PL/Java to be built without any
> external modules at all. It's then completely up to the user what he/she
> wants to slot in as a replacement.

Do we want to do that? I mean (and I am not saying it is, I am asking)
is that a bit grey? I would prefer it be black and white.

Are their JVMs that are BSD compatible? It is my understanding that you
can ship Java (I could be completely on crack here) in a closed source
product without issue right?

If so... then wouldn't our argument be to strongly suggest that they use
the Sun JVM (or IBM if that is relevant?).

Sincerely,

Joshua D. Drake

>
> Regards,
> Thomas Hallgren
>

--

=== The PostgreSQL Company: Command Prompt, Inc. ===
Sales/Support: +1.503.667.4564 || 24x7/Emergency: +1.800.492.2240
Providing the most comprehensive PostgreSQL solutions since 1997
http://www.commandprompt.com/

Joshua D. Drake wrote:
>
>> Well, assume that FSF indeed did remove the exception. It would take
>> me 30 minutes or so to create a substitute BSD licensed dummy JNI
>> library with associated headers that would allow PL/Java to be built
>> without any external modules at all. It's then completely up to the
>> user what he/she wants to slot in as a replacement.
>
> Do we want to do that? I mean (and I am not saying it is, I am asking)
> is that a bit grey? I would prefer it be black and white.
>
The JNI API is an open standard so I have every right to create a BSD
licensed dummy for it. The user may choose a JVM from IBM, Sun, BEA, or
other (like GCJ) to run. That's the essence of having a standardized
API. What can possibly be 'grey' about that?

Regards,
Thomas Hallgren

Thomas Hallgren wrote:
> Joshua D. Drake wrote:
>> What happens when the FSF inevitably removes the license clause and
>> makes it pure GPL?
>>
> I'm sorry but I don't follow. You're saying that it's inevitable that
> FSF will remove the 'libgcc' exception from libgcj? Why on earth would
> they do that? My guess is that it will go the other way (i.e. LGPL).
> What's the logic in having different licenses on libg++ and libgcj?

You are trying to apply logic to what is a political organization. Keep
in mind that LGPL stands for LESSOR GPL. RMS would prefer that ALL
licenses be under the GPL (or something very similar) that does not
allow anyone to close source the software.

This isn't really the point of the thread though.

Sincerely,

Joshua D. Drake

>
>> Now all of this being said, I doubt there is actually an issue here
>> because:
>>
>> It doesn't HAVE TO BE BUILT, it is not a derivative product.
>>
> Well, assume that FSF indeed did remove the exception. It would take me
> 30 minutes or so to create a substitute BSD licensed dummy JNI library
> with associated headers that would allow PL/Java to be built without any
> external modules at all. It's then completely up to the user what he/she
> wants to slot in as a replacement.
>
> Regards,
> Thomas Hallgren
>
>
> ---------------------------(end of broadcast)---------------------------
> TIP 6: explain analyze is your friend
>

--

=== The PostgreSQL Company: Command Prompt, Inc. ===
Sales/Support: +1.503.667.4564 || 24x7/Emergency: +1.800.492.2240
Providing the most comprehensive PostgreSQL solutions since 1997
http://www.commandprompt.com/

Will this patch make it into 8.2?
http://archives.postgresql.org/pgsql-patches/2004-12/msg00228.php

It's a really nice feature, would be extremly useful with tools like pgpool.

Am Freitag, 7. Juli 2006 19:13 schrieb Bruce Momjian:
> 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(at)momjian(dot)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

Thomas,

> OK. You're the one that suggested this submission attempt. There's not
> much point in pursuing it if you have second thoughts.

Yes. I was unclear on the requirements. I was thinking of it being
"just like PL/perl".

> Right, something that would allow PL/Java to participate in a build

Unfortunately, it's not exactly an easy task.

--Josh

On 7/13/06, Josh Berkus <josh(at)agliodbs(dot)com> wrote:
> I'm starting to have second thoughts about this suggestion. I was
> enthusiastic about it at the summit, but I was unaware of the sheer size
> of PL/Java. 38,000 lines of code is 8% of the total size of Postgresql
> ... for *one* PL.

Josh,

I still don't see the problem; 38K lines of code really isn't that
much. I have personal proof-of-concept projects bigger than that.
The question really is whether it's going to be maintained and by
whom. Tom, Neil, et al will not be the ones maintaining it on a
regular basis.

> Dave Cramer acquainted me with some of the difficulties of doing a Java
> PL today, and I understand why it needs to be that large. However,
> 38,000 lines of code -- much of it in a non-C language -- presents a
> possible debugging/maintenance major headache, especially if you someday
> left the project for some reason.

Again, I guess it comes down to what we're willing to let go. If we
want new users who want certain functionality in the system to be
happy, we include it. Otherwise, we do as we do now, keeping tons of
projects on pgfoundry and hoping a user doesn't just pass us by
because they installed PostgreSQL and didn't see the things they
want/need in the core. Of course, this will last until MySQL goes
ahead and adds a Java PL and the user doesn't even glance over at
us... but I guess that falls back to the argument of, "what kind of
user do we really want". Almost everyone here who's ever done
real-world consulting on PostgreSQL has run into PL/Java at some point
in time, so it is used and used often.

> This attitude does you no credit, Thomas.

That may be, but I completely understand Thomas' frustration. This
topic wasn't his idea yet his project is being bashed on pretty well.
If you know of some way to turn 38K lines of code into 5K, or can
magically translate Java code to C, he may be open to it... but
complaining about something someone spent free-time on devotedly for
several years is just going to cause problems... neither is making
arguments by comparing it to a much less complete implementation.

The point is, this is just politics without common sense. PL/Java
works and works well, if you haven't used it or PL/J, please don't
talk about it like you know it; it just spreads misinformation through
the forum. The fact is that a lot of people use PL/Java, you asked
about including it in the core, it's a stable PL, and Thomas is
willing to continue maintaining and improving it. My vote is that we
add it to the core and let him continue to do so.

As for the JVM worries, it's perfectly fine for anyone to ship the
JVM. If we wanted to include the JVM in official PostgreSQL
distributions, we can do so. Otherwise, we can just rely on the user
to have a JVM installed. Better yet, Sun supports PostgreSQL, so get
them to do a specific distribution license. There aren't that many
options so I don't see the need to plan contingencies ad nauseam.

I don't believe anyone has offered any suggestions or good
alternatives other than what we have now; keeping high-profile
projects like PL/Java on gborg/pgfoundry (which sucks IMHO).

--
Jonah H. Harris, Software Architect | phone: 732.331.1300
EnterpriseDB Corporation | fax: 732.331.1301
33 Wood Ave S, 2nd Floor | jharris(at)enterprisedb(dot)com
Iselin, New Jersey 08830 | http://www.enterprisedb.com/

On 7/12/06, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> wrote:
> > I don't really think anyone would want to run both, but
> > that's just my opinion.
>
> On what grounds do you not think that?

Too much Java overhead on one database and PL/J isn't that stable.
I've run into several crash problems with it before.

> PL/J uses an external JVM, PL/Java one that is running in the
> backend process. (Or maybe it was the other way 'round, I'm too
> tired to remember tonight.)

While tired, you're still correct :)

> That's a really fundamental difference that makes them suited for very different
> applications; not to mention the resulting different licensing scenarios.

Not really, both require a JVM so the same licensing still applies.

> The points that have been made in this thread about PL/J not being
> actively maintained are important, but other than that objection,
> I can see no reason that PL/J wouldn't have an equal claim to inclusion
> in core.

I'm being objective here, and PL/J is not nearly as stable or
well-maintained... that means a lot to me or to anyone who looks at
using a Java PL. Do we intend to ship both and say that one is less
capable? Have you used either of them? Don't get me wrong, I like
PL/J in concept... but it's just not even close to production-ready
yet. I know of no one using PL/J in production and about 40 or so
people using PL/Java.

> Perhaps more, because it gives us an extra layer of insulation
> from JVM licensing questions.

Again, I don't believe so. I'd like to hear how Dave thinks so, though.

--
Jonah H. Harris, Software Architect | phone: 732.331.1300
EnterpriseDB Corporation | fax: 732.331.1301
33 Wood Ave S, 2nd Floor | jharris(at)enterprisedb(dot)com
Iselin, New Jersey 08830 | http://www.enterprisedb.com/

* Joshua D. Drake (jd(at)commandprompt(dot)com) wrote:
> Keep in mind that that there are all kinds of oddities when mixing
> licenses. Is Sun's JVM GPL compatible? If not, the plJava can't use it.

I'm about 95% sure that Sun's JVM *isn't* GPL compatible... Makes for a
pretty odd situation if someone licensed a Java app which only works
with Sun's JVM under the GPL. The combination of the Java app with
Sun's JVM then becomes impossible to distribute. This is more a problem
with the GPL's 'no additional restrictions' clause than anything else,
but, well, the GPL is pretty popular. :/

> It doesn't HAVE TO BE BUILT, it is not a derivative product.

Many distributions try to build all the parts of a given application
since otherwise someone will almost certainly ask for it. Therefore,
I'm not really sure this is a great argument.

> It doesn't ship with the JVM which means it is up to the user to break
> the license not the PostgreSQL project...

It's not the PostgreSQL project's problem, that's true, but it certainly
becomes an issue for distributions. Java as a PL ends up being a pretty
odd case.. If there isn't anything in the PL code itself which forces a
dependency beyond gcj then it might be possible to distribute it. Also
allowing the PL to use a different JVM shouldn't be a problem so long as
nothing is distributed which depends on the alternate JVM. The GPL is
all about distribution and so I'm not sure that it would actually be a
problem for an end-user to use Sun's JVM with GPL'd Java code.

Anyhow, if people are really interested in these issues as they relate
to a distribution, it might make sense to bring it up on debian-legal...

Thanks,

Stephen

On 13-Jul-06, at 9:22 AM, Jonah H. Harris wrote:

> On 7/13/06, Josh Berkus <josh(at)agliodbs(dot)com> wrote:
>> I'm starting to have second thoughts about this suggestion. I was
>> enthusiastic about it at the summit, but I was unaware of the
>> sheer size
>> of PL/Java. 38,000 lines of code is 8% of the total size of
>> Postgresql
>> ... for *one* PL.
>
> Josh,
>
> I still don't see the problem; 38K lines of code really isn't that
> much. I have personal proof-of-concept projects bigger than that.
> The question really is whether it's going to be maintained and by
> whom. Tom, Neil, et al will not be the ones maintaining it on a
> regular basis.
>
>> Dave Cramer acquainted me with some of the difficulties of doing a
>> Java
>> PL today, and I understand why it needs to be that large. However,
>> 38,000 lines of code -- much of it in a non-C language -- presents a
>> possible debugging/maintenance major headache, especially if you
>> someday
>> left the project for some reason.
>
> Again, I guess it comes down to what we're willing to let go. If we
> want new users who want certain functionality in the system to be
> happy, we include it. Otherwise, we do as we do now, keeping tons of
> projects on pgfoundry and hoping a user doesn't just pass us by
> because they installed PostgreSQL and didn't see the things they
> want/need in the core. Of course, this will last until MySQL goes
> ahead and adds a Java PL and the user doesn't even glance over at
> us... but I guess that falls back to the argument of, "what kind of
> user do we really want". Almost everyone here who's ever done
> real-world consulting on PostgreSQL has run into PL/Java at some point
> in time, so it is used and used often.
>
>> This attitude does you no credit, Thomas.
>
> That may be, but I completely understand Thomas' frustration. This
> topic wasn't his idea yet his project is being bashed on pretty well.
> If you know of some way to turn 38K lines of code into 5K, or can
> magically translate Java code to C, he may be open to it... but
> complaining about something someone spent free-time on devotedly for
> several years is just going to cause problems... neither is making
> arguments by comparing it to a much less complete implementation.
>
> The point is, this is just politics without common sense. PL/Java
> works and works well, if you haven't used it or PL/J, please don't
> talk about it like you know it; it just spreads misinformation through
> the forum. The fact is that a lot of people use PL/Java, you asked
> about including it in the core, it's a stable PL, and Thomas is
> willing to continue maintaining and improving it. My vote is that we
> add it to the core and let him continue to do so.
>
> As for the JVM worries, it's perfectly fine for anyone to ship the
> JVM. If we wanted to include the JVM in official PostgreSQL
> distributions, we can do so. Otherwise, we can just rely on the user
> to have a JVM installed. Better yet, Sun supports PostgreSQL, so get
> them to do a specific distribution license. There aren't that many
> options so I don't see the need to plan contingencies ad nauseam.
>
> I don't believe anyone has offered any suggestions or good
> alternatives other than what we have now; keeping high-profile
> projects like PL/Java on gborg/pgfoundry (which sucks IMHO).
>

The official JDBC driver is not being shipped with the project for
exactly the same reasons, I fail to see any compelling reason to ship
either java PL.

Unless we are going to create a complete distribution with a unified
build, or at least a way to build each project (which I am in favour
of) then we leave the server to itself and all other projects exist
separately.

> --
> Jonah H. Harris, Software Architect | phone: 732.331.1300
> EnterpriseDB Corporation | fax: 732.331.1301
> 33 Wood Ave S, 2nd Floor | jharris(at)enterprisedb(dot)com
> Iselin, New Jersey 08830 | http://www.enterprisedb.com/
>

On 13-Jul-06, at 9:29 AM, Jonah H. Harris wrote:

> On 7/12/06, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> wrote:
>> > I don't really think anyone would want to run both, but
>> > that's just my opinion.
>>
>> On what grounds do you not think that?
>
> Too much Java overhead on one database and PL/J isn't that stable.
> I've run into several crash problems with it before.
>
>> PL/J uses an external JVM, PL/Java one that is running in the
>> backend process. (Or maybe it was the other way 'round, I'm too
>> tired to remember tonight.)
>
> While tired, you're still correct :)
>
>> That's a really fundamental difference that makes them suited for
>> very different
>> applications; not to mention the resulting different licensing
>> scenarios.
>
> Not really, both require a JVM so the same licensing still applies.
>
>> The points that have been made in this thread about PL/J not being
>> actively maintained are important, but other than that objection,
>> I can see no reason that PL/J wouldn't have an equal claim to
>> inclusion
>> in core.
>
> I'm being objective here, and PL/J is not nearly as stable or
> well-maintained... that means a lot to me or to anyone who looks at
> using a Java PL.
Doesn't EDB sponsor pl/java ? I would think that might make you
somewhat subjective ?

That being said, pl-j is not as mature as pl/java, however I don't
believe that is a valid reason for exclusion.
Open source projects by their nature gain maturity by exposure.

> Do we intend to ship both and say that one is less
> capable? Have you used either of them? Don't get me wrong, I like
> PL/J in concept... but it's just not even close to production-ready
> yet. I know of no one using PL/J in production and about 40 or so
> people using PL/Java.
>
>> Perhaps more, because it gives us an extra layer of insulation
>> from JVM licensing questions.
>
> Again, I don't believe so. I'd like to hear how Dave thinks so,
> though.

I didn't say this
>
> --
> Jonah H. Harris, Software Architect | phone: 732.331.1300
> EnterpriseDB Corporation | fax: 732.331.1301
> 33 Wood Ave S, 2nd Floor | jharris(at)enterprisedb(dot)com
> Iselin, New Jersey 08830 | http://www.enterprisedb.com/
>

On 7/13/06, Dave Cramer <pg(at)fastcrypt(dot)com> wrote:
> The official JDBC driver is not being shipped with the project for
> exactly the same reasons, I fail to see any compelling reason to ship
> either java PL.

IMHO, we should be shipping the JDBC driver... but that's another
matter entirely.

> Unless we are going to create a complete distribution with a unified
> build, or at least a way to build each project (which I am in favour
> of) then we leave the server to itself and all other projects exist
> separately.

This still doesn't solve the longstanding issue of what we do include
and what we don't... and more importantly, the process for determining
what to include and what not to. The Java PL discussion could be the
same as say, OBDC drivers... where multiple projects exist and each
has pros/cons.

When someone downloads the PostgreSQL server on Windows... we know
they're probably going to be using ODBC... so we should ship it; but
which one? How do we determine which one as a community?

Eventually we need to evolve a little bit and tackle these types of
issues; I don't think gborg or pgfoundry are the best places for
high-profile, commonly used PostgreSQL drivers, PLs, or functions.

--
Jonah H. Harris, Software Architect | phone: 732.331.1300
EnterpriseDB Corporation | fax: 732.331.1301
33 Wood Ave S, 2nd Floor | jharris(at)enterprisedb(dot)com
Iselin, New Jersey 08830 | http://www.enterprisedb.com/

On Thu, 2006-07-13 at 15:29, Stephen Frost wrote:
> It's not the PostgreSQL project's problem, that's true, but it certainly
> becomes an issue for distributions. Java as a PL ends up being a pretty
> odd case.. If there isn't anything in the PL code itself which forces a
> dependency beyond gcj then it might be possible to distribute it. Also
> allowing the PL to use a different JVM shouldn't be a problem so long as
> nothing is distributed which depends on the alternate JVM. The GPL is
> all about distribution and so I'm not sure that it would actually be a
> problem for an end-user to use Sun's JVM with GPL'd Java code.

Now I'm completely confused... what GPL code ? Is PL/Java licensed under
the GPL ? Or what GPL code do you talk about ?

The PL/Java code is likely only dependent on the JVM specification,
which does not put any restriction on how you must license your code, so
PL/Java can be licensed in any way the author wants, including BSD.

The distribution part is also no problem as I see it, as only the build
tools are not BSD, and they are available for free (including the Sun
JDK) and they don't restrict what should be the license of the code you
compile. This can only be a problem for purists like GPL zealots or
perhaps debian, otherwise is not that hard to download and install the
SUN JDK on a build machine... you don't need to distribute the JDK, only
the runtime JVM, which you actually can do (including again the Sun
runtime). So I can't see problems again from the packager point of
view... except purists might put a separate pl/Java module in some
"non-free" repository given the dependency on some "non-free" runtime...

Cheers,
Csaba.

On Thu, Jul 13, 2006 at 09:29:06AM -0400, Jonah H. Harris wrote:
> I'm being objective here, and PL/J is not nearly as stable or
> well-maintained... that means a lot to me or to anyone who looks at
> using a Java PL. Do we intend to ship both and say that one is less
> capable? Have you used either of them? Don't get me wrong, I like
> PL/J in concept... but it's just not even close to production-ready
> yet. I know of no one using PL/J in production and about 40 or so
> people using PL/Java.

On the subject of 38K lines of code, much that isn't C (going by memory,
I apologize if this is wrong), how many of these lines could be/should be
shared between PL/Java and PL/J? It seems to me that the general concepts
should be in common, and that it is only how the Java interfaces with the
backend that changes. Could they not be one PL, with two mechanisms for
speaking to the backend?

I agree with competition to improve quality, but at some point, with
too few maintainers, and one project clearly more advanced in terms of
maturity than the other, that perhaps having two separate projects
does not make sense. It sounds to me like PL/Java is rich in terms of
PostgreSQL abstractions, and that this shouldn't be a reason to
penalize it. Does it really matter how much Java code there is in it?
It's only the C code that needs to interface with the backend.

Or perhaps I'm out to lunch, and the PL/Java abstractions are tightly
tied to the backend API, and there is thousands of lines of unnecessary
code.

Now you are going to make me try them both out. I have not tried either.

Cheers,
mark

--
mark(at)mielke(dot)cc / markm(at)ncf(dot)ca / markm(at)nortel(dot)com __________________________
. . _ ._ . . .__ . . ._. .__ . . . .__ | Neighbourhood Coder
|\/| |_| |_| |/ |_ |\/| | |_ | |/ |_ |
| | | | | \ | \ |__ . | | .|. |__ |__ | \ |__ | Ottawa, Ontario, Canada

One ring to rule them all, one ring to find them, one ring to bring them all
and in the darkness bind them...

http://mark.mielke.cc/

On 7/13/06, Dave Cramer <pg(at)fastcrypt(dot)com> wrote:
> Doesn't EDB sponsor pl/java ? I would think that might make you
> somewhat subjective ?

I believe we do, but that has nothing to do with my statements. I've
used both PL/Java and PL/J before coming to EnterpriseDB and am making
true observations.

> That being said, pl-j is not as mature as pl/java, however I don't
> believe that is a valid reason for exclusion.

So, I was being objectionable then...

> Open source projects by their nature gain maturity by exposure.

Open source projects gain maturity through continued improvement and
maintenance... I can name hundreds of cool open source projects I've
used that have died because they were once popular, but no one
maintained them on a consistent basis.

--
Jonah H. Harris, Software Architect | phone: 732.331.1300
EnterpriseDB Corporation | fax: 732.331.1301
33 Wood Ave S, 2nd Floor | jharris(at)enterprisedb(dot)com
Iselin, New Jersey 08830 | http://www.enterprisedb.com/

Jonah H. Harris wrote:

> Again, I guess it comes down to what we're willing to let go. If we
> want new users who want certain functionality in the system to be
> happy, we include it. Otherwise, we do as we do now, keeping tons of
> projects on pgfoundry and hoping a user doesn't just pass us by
> because they installed PostgreSQL and didn't see the things they
> want/need in the core. Of course, this will last until MySQL goes
> ahead and adds a Java PL and the user doesn't even glance over at
> us... but I guess that falls back to the argument of, "what kind of
> user do we really want". Almost everyone here who's ever done
> real-world consulting on PostgreSQL has run into PL/Java at some point
> in time, so it is used and used often.

Aside from obviously the big issue of who maintains all the pgfoundry
stuff, I also think that the PostgreSQL family would benefit from a
distribution that is more "and the kitchen sink" style. I do not know
exactly if Bizgres could be considered just that? Or maybe it could get
promoted to be that?

What I mean is I think it makes absolute sense to keep a very stable,
very well maintained core PostgreSQL distribution which is that anyone
should base their distributions on. However I do think that PostgreSQL
is missing out in getting new users aboard that are in the early stages
of evalutation and simply only consider features that they get along
with a default installation (mostly due to lack of better knowledge
about places like pgfoundry). For these kinds of users it would make
sense to provide a distro that has an extended feature list, while
sacrificing maybe a tiny bit of stability because it adds modules that
do not adhere to the same high level of maintaince as PostgreSQL core does.

regards,
Lukas

Forwarded to -hackers.

Jonah H. Harris wrote:
> Again, I guess it comes down to what we're willing to let go. If we
> want new users who want certain functionality in the system to be
> happy, we include it. Otherwise, we do as we do now, keeping tons of
> projects on pgfoundry and hoping a user doesn't just pass us by
> because they installed PostgreSQL and didn't see the things they
> want/need in the core. Of course, this will last until MySQL goes
> ahead and adds a Java PL and the user doesn't even glance over at
> us... but I guess that falls back to the argument of, "what kind of
> user do we really want". Almost everyone here who's ever done
> real-world consulting on PostgreSQL has run into PL/Java at some point
> in time, so it is used and used often.

Aside from obviously the big issue of who maintains all the pgfoundry
stuff, I also think that the PostgreSQL family would benefit from a
distribution that is more "and the kitchen sink" style. I do not know
exactly if Bizgres could be considered just that? Or maybe it could get
promoted to be that?

What I mean is I think it makes absolute sense to keep a very stable,
very well maintained core PostgreSQL distribution which is that anyone
should base their distributions on. However I do think that PostgreSQL
is missing out in getting new users aboard that are in the early stages
of evalutation and simply only consider features that they get along
with a default installation (mostly due to lack of better knowledge
about places like pgfoundry). For these kinds of users it would make
sense to provide a distro that has an extended feature list, while
sacrificing maybe a tiny bit of stability because it adds modules that
do not adhere to the same high level of maintaince as PostgreSQL core does.

regards,
Lukas

Dave Cramer <pg(at)fastcrypt(dot)com> writes:
> The official JDBC driver is not being shipped with the project for
> exactly the same reasons, I fail to see any compelling reason to ship
> either java PL.

> Unless we are going to create a complete distribution with a unified
> build, or at least a way to build each project (which I am in favour
> of) then we leave the server to itself and all other projects exist
> separately.

The only argument I find interesting for including the PLs in core
(which has zilch to do with how any particular packager ships them)
is that it's easier to do maintenance that way: if we make a change in
an API that affects the PLs, we can change the PLs at the same time.
However, that argument only holds water if the core developers are
able/willing to make the corresponding changes. And in that light,
the fact that PL/Java includes a huge whack of non-C code is very
significant. *I* won't take responsibility for fixing PL/Java when
I break it, because I don't know Java well enough. I don't know what
other people who do core development feel about that --- but I dislike
the idea that when someone changes such an API, the buildfarm will go
all red because there's only one person with the ability to fix PL/Java.

regards, tom lane

On 7/13/06, Lukas Smith wrote:
> However I do think that PostgreSQL is missing out in
> getting new users aboard that are in the early stages
> of evalutation and simply only consider features that
> they get along with a default installation (mostly due
> to lack of better knowledge about places like pgfoundry).

This is my point exactly. As with many things, we keep skirting the
real issue by going with an "improve the smaller component" approach
such as "promote pgfoundry more". I have never seen this approach
work, but maybe someone has an example of another OSS project that has
successfully excluded major components like this?

No matter what we want people to do, if someone wants PostgreSQL, they
go to PostgreSQL's site, download PostgreSQL, and install PostgreSQL.
The fact is, most people generally don't read the, "don't see it in
the distribution, check out pgfoundry"-like text. Sure, people should
read the docs, but most don't until they have to (which is long after
getting the software). Do we even have anything in the actual manual
that talks about gborg or pgfoundry?

> For these kinds of users it would make sense to provide
> a distro that has an extended feature list, while sacrificing
> maybe a tiny bit of stability

I don't see it as less stable at all. If someone needs functionality
(and doesn't just decide to get a different RDBMS that has it
included), they're going to get the pgfoundry project anyway... so
whether we include it in the distro is seemingly irrelevant from a
stability standpoint. What we should say is something to the effect
of, "this version of [pgfoundry project X] has been tested
successfully with PostgreSQL x.x.x." The core distro has nothing to
do with the add-ons which are inevitably added by the user after the
fact... but at least we wouldn't lose potentially new users.

My question is, what is the packagers' stance on this topic? It seems
like more work for them than for anyone else.

--
Jonah H. Harris, Software Architect | phone: 732.331.1300
EnterpriseDB Corporation | fax: 732.331.1301
33 Wood Ave S, 2nd Floor | jharris(at)enterprisedb(dot)com
Iselin, New Jersey 08830 | http://www.enterprisedb.com/

On 7/13/06, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> wrote:
> The only argument I find interesting for including the PLs in core
> (which has zilch to do with how any particular packager ships them)
> is that it's easier to do maintenance that way: if we make a change in
> an API that affects the PLs, we can change the PLs at the same time.

Very true.

> However, that argument only holds water if the core developers are
> able/willing to make the corresponding changes.

Again, this is very true as well.

> in that light, the fact that PL/Java includes a huge whack of
> non-C code is very significant. *I* won't take responsibility
> for fixing PL/Java when I break it, because I don't know Java
> well enough.

I don't think anyone expects you to. I certainly feel that PostgreSQL
is a community... we all suffer if no one steps up to help fix
something that's busted. We all rely on eachother in one way or
another, and I don't see something as important as a fairly mature PL
getting dumped on anyone... there's a lot of Java people out there
that could maintain it if Thomas doesn't want to someday, or we can
remove it altogether if it starts to compromise the core... but I see
a lot of work that's been done over several years and Thomas has
stepped up to the plate each time there has been some incompatibility
or issue between PostgreSQL and PL/Java; I see no reason why this
wouldn't be the case going forward.

> I don't know what other people who do core development feel
> about that --- but I dislike the idea that when someone changes
> such an API, the buildfarm will go all red because there's only
> one person with the ability to fix PL/Java.

There's many of us that *can* fix it... I'm a Java developer as well,
but I wouldn't choose to work on PL/Java by default because that's not
my area of interest. If, however, the core was suffering from an
issue with it, personal interests aren't as relevant.

Again, we all rely on one another... I'm optimistic that we can make
these types of things work out successfully.

--
Jonah H. Harris, Software Architect | phone: 732.331.1300
EnterpriseDB Corporation | fax: 732.331.1301
33 Wood Ave S, 2nd Floor | jharris(at)enterprisedb(dot)com
Iselin, New Jersey 08830 | http://www.enterprisedb.com/

On Thu, July 13, 2006 11:03 am, Jonah H. Harris wrote:
> This is my point exactly. As with many things, we keep skirting the
> real issue by going with an "improve the smaller component" approach such
> as "promote pgfoundry more". I have never seen this approach work, but
> maybe someone has an example of another OSS project that has successfully
> excluded major components like this?

Perl? CPAN? Many modules are included but how they are chosen is somewhat
arbitrary. However, those modules can be updated from CPAN (without
redownloading Perl).

Am Donnerstag, 13. Juli 2006 16:48 schrieb Jonah H. Harris:
> What I mean is I think it makes absolute sense to keep a very stable,
> very well maintained core PostgreSQL distribution which is that anyone
> should base their distributions on.

I don't want to get into an operating system bout here, but there are a number
of systems out there that include a fair amount of PostgreSQL-related
software in packaged and readily available form, and will accept your
contribution if anything is missing.

I seriously doubt that providing one big PostgreSQL *source* distribution will
help that process in any way.

--
Peter Eisentraut
http://developer.postgresql.org/~petere/

On Thu, Jul 13, 2006 at 11:03:27AM -0400, Tom Lane wrote:
> The only argument I find interesting for including the PLs in core
> (which has zilch to do with how any particular packager ships them)
> is that it's easier to do maintenance that way: if we make a change in
> an API that affects the PLs, we can change the PLs at the same time.

> However, that argument only holds water if the core developers are
> able/willing to make the corresponding changes. And in that light,
> the fact that PL/Java includes a huge whack of non-C code is very
> significant. *I* won't take responsibility for fixing PL/Java when
> I break it, because I don't know Java well enough. I don't know what
> other people who do core development feel about that --- but I dislike
> the idea that when someone changes such an API, the buildfarm will go
> all red because there's only one person with the ability to fix PL/Java.

Tom:

Currently, the PL implementations combine both language-specific glue
and language-specific abstractions together. In light of your comments
below, and the opinion I expressed in my previous response, I find
myself wondering whether this architecture is contributing to the
problem.

Would it make sense for this architecture to be split?

My thinking is that much of the code in the Perl, TCL, Java, ... PL
implementations is related to language-specific abstractions and
documentation, and does not need to be bundled with the core, nor
does it need to be tested as a part of the core. For example, I imagine
that many of the lines in PL/Java could be distributed as a single
hardware-independent .jar file separate from the core, if the core
exposed the required API to Java.

Where this could go, is that the core developers would only be
responsible for ensuring that the backend API functions as documented,
without needing to understand how these functions are exposed to the
user. You agree to maintain Java interfaces to the C functions. No more,
no less. If somebody else wants to build complicated abstractions on top,
or wants to provide thousands of pages of documentation - this is their
choice, but would be distributed separate from the core, but would be
simple to plug in.

Am I just spitting crazy talk, or is this making sense?

Cheers,
mark

--
mark(at)mielke(dot)cc / markm(at)ncf(dot)ca / markm(at)nortel(dot)com __________________________
. . _ ._ . . .__ . . ._. .__ . . . .__ | Neighbourhood Coder
|\/| |_| |_| |/ |_ |\/| | |_ | |/ |_ |
| | | | | \ | \ |__ . | | .|. |__ |__ | \ |__ | Ottawa, Ontario, Canada

One ring to rule them all, one ring to find them, one ring to bring them all
and in the darkness bind them...

http://mark.mielke.cc/

On Thu, 2006-07-13 at 17:03, Tom Lane wrote:
> [...] I don't know what
> other people who do core development feel about that --- but I dislike
> the idea that when someone changes such an API, the buildfarm will go
> all red because there's only one person with the ability to fix PL/Java.

But the alternative is that nothing is going red, and the PL stays
broken until somebody notices it which might be too late to easily know
which change broke it.

Wouldn't it be possible to separate the "red/green lights" for the core
and for the PLs ? So the core stays green and the PLs go red... and stay
red until the PL maintainer fixes things.

And I don't believe there's only one man who knows good Java around...
once PL/Java gets in the core I'm pretty sure there will be a lot of
people using it and caring about it.

Cheers,
Csaba.

On Thu, 2006-07-13 at 11:03 -0400, Jonah H. Harris wrote:
> On 7/13/06, Lukas Smith wrote:
> > However I do think that PostgreSQL is missing out in
> > getting new users aboard that are in the early stages
> > of evalutation and simply only consider features that
> > they get along with a default installation (mostly due
> > to lack of better knowledge about places like pgfoundry).
>
> This is my point exactly. As with many things, we keep skirting the
> real issue by going with an "improve the smaller component" approach
> such as "promote pgfoundry more". I have never seen this approach
> work, but maybe someone has an example of another OSS project that has
> successfully excluded major components like this?

Personally, I prefer the Gnome approach. Most components are developed
and bundled independently but once the code meets certain stability and
usability requirements the component is promoted to the standard website
with standard documentation, bug reporting, download locations, etc.

On PostgreSQL.org, aside from the "Downloads" tab it is very difficult
to find these items. PGFoundry does not attempt to differentiate between
the state of projects. Top downloads is the closest to this.

XML based docbook can easily suck in documentation from multiple remote
sources (when available -- substituted when not available) for a single
documentation build via XMLIncludes. This allows for PL/Java chapter in
the standard documentation set online.

PostgreSQL.org "Support" could pretty easily link to the various
locations for bug reports -- Bugzilla makes component selection a common
requirement.

A slight restructuring of the FTP tree should probably be made. It's
currently very easy to find the main pgsql, pgadmin and odbc components.
Finding pl/java (what the heck is that gborg or pgfoundry project?) is
pretty difficult.

The only real tricky part is defining what a plugin or addon application
such as pgadmin needs to be considered production ready. This will
relate to testing practices, documentation, code quality, ongoing
maintenance, and expected supported lifetime. For lifetime, if it was
released for Core 7.3 should still work with 7.3 today or old versions
should still receive security and bug fixes.

--

Tom Lane wrote:
> Dave Cramer <pg(at)fastcrypt(dot)com> writes:
> > The official JDBC driver is not being shipped with the project for
> > exactly the same reasons, I fail to see any compelling reason to ship
> > either java PL.
>
> > Unless we are going to create a complete distribution with a unified
> > build, or at least a way to build each project (which I am in favour
> > of) then we leave the server to itself and all other projects exist
> > separately.
>
> The only argument I find interesting for including the PLs in core
> (which has zilch to do with how any particular packager ships them)
> is that it's easier to do maintenance that way: if we make a change in
> an API that affects the PLs, we can change the PLs at the same time.
> However, that argument only holds water if the core developers are
> able/willing to make the corresponding changes. And in that light,
> the fact that PL/Java includes a huge whack of non-C code is very
> significant. *I* won't take responsibility for fixing PL/Java when
> I break it, because I don't know Java well enough. I don't know what
> other people who do core development feel about that --- but I dislike
> the idea that when someone changes such an API, the buildfarm will go
> all red because there's only one person with the ability to fix PL/Java.

I also cannot maintain Java, but we could do something like we do with
WIN32, where outside folks submit patches to fix problems.

--
Bruce Momjian bruce(at)momjian(dot)us
EnterpriseDB http://www.enterprisedb.com

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

mark(at)mark(dot)mielke(dot)cc wrote:
> On the subject of 38K lines of code, much that isn't C (going by memory,
> I apologize if this is wrong), how many of these lines could be/should be
> shared between PL/Java and PL/J? It seems to me that the general concepts
> should be in common, and that it is only how the Java interfaces with the
> backend that changes. Could they not be one PL, with two mechanisms for
> speaking to the backend?
>
By all means. An embedded JVM solution should share as much as possible with one that uses a
remote JVM. From the users perspective there should be no difference at all. PL/Java is
designed with this in mind. The class loader and the utility commands are based on JDBC, the
security manager that enables the choice of trusted/untrusted execution is Java standard. A
set of interfaces for non-standard access (PostgreSQL TriggerData in particular) was
abstracted in order to allow different implementations. Etc.

That said, there is also code that deals with tight backend integration and is highly
specialized to fit the embedded solution. This code is designed around the fact that
function calls to the backend are very cheap. As an example, PL/Java contains a JDBC driver
that is written directly on top of the SPI API. The involved C-structures are rarely copied
or streamed. They are accessed directly using JNI functions.

I've spent some time lately, investigating what it would take to complement PL/Java with a
remote JVM option. The major challenge lays in the impedance mismatch caused by concerns
that one must consider when using RPC (limit the number of calls) compared to the current
design (avoid copying and streaming).

Kind regards,
Thomas Hallgren

Tom Lane wrote:

>Dave Cramer <pg(at)fastcrypt(dot)com> writes:
>
>
>>The official JDBC driver is not being shipped with the project for
>>exactly the same reasons, I fail to see any compelling reason to ship
>>either java PL.
>>
>>
>
>
>
>>Unless we are going to create a complete distribution with a unified
>>build, or at least a way to build each project (which I am in favour
>>of) then we leave the server to itself and all other projects exist
>>separately.
>>
>>
>
>The only argument I find interesting for including the PLs in core
>(which has zilch to do with how any particular packager ships them)
>is that it's easier to do maintenance that way: if we make a change in
>an API that affects the PLs, we can change the PLs at the same time.
>
>

Yes, exactly. And if you look back at the history of, say, plperl.c, you
will find plenty of such instances.

>However, that argument only holds water if the core developers are
>able/willing to make the corresponding changes. And in that light,
>the fact that PL/Java includes a huge whack of non-C code is very
>significant. *I* won't take responsibility for fixing PL/Java when
>I break it, because I don't know Java well enough. I don't know what
>other people who do core development feel about that --- but I dislike
>the idea that when someone changes such an API, the buildfarm will go
>all red because there's only one person with the ability to fix PL/Java.
>
>
>

I take your point. I do have some java-fu, but I don't know how many
other committers do, for example.

The sad truth is that an effort to be absolutely fair and treat everyone
the same may result in some PLs being worse off without any getting
better off. I don't think we should aim at a Pareto disimprovement. Has
it worked well in the case of client libraries? I am not sure it has.

One thing is for sure, we need to do some proselytizing among packagers
to make sure they pick up more than just what is in core.

cheers

andrew

Bruce Momjian <bruce(at)momjian(dot)us> writes:
> I also cannot maintain Java, but we could do something like we do with
> WIN32, where outside folks submit patches to fix problems.

However, a win32 failure breaks only the win32 buildfarm members ...

Basically my point here is that I see no synergy from having PL/Java
(or PL/J for that matter) in core. They can't share the same configure
or build support as the rest of the code; the core developers don't feel
qualified to maintain them; what's left?

The argument in favor boils down to one and only one thing: bundling
PL/Java will improve the visibility of PL/Java to people who won't go
looking for it. That's fine, but ultimately that's a packaging argument
not a development argument. The people who think PL/Java is an
essential checklist item undoubtedly also think JDBC is an essential
checklist item, but I'm not seeing any groundswell of support for
putting JDBC back into core. Instead we expect packagers (like the RPM
set) to make JDBC available alongside the core postgres packages.
That's how PL/Java ought to be handled, too, IMHO.

In my own experience dealing with the Red Hat RPMs, it got a whole lot
easier to package JDBC correctly once it wasn't mis-bundled into a
basically non-Java source tarball, so I think that the packagers will
also find that keeping it separate makes their lives easier.

regards, tom lane

>> I'm being objective here, and PL/J is not nearly as stable or
>> well-maintained... that means a lot to me or to anyone who looks at
>> using a Java PL.
> Doesn't EDB sponsor pl/java ? I would think that might make you somewhat
> subjective ?

Dave,

I don't think so in this situation. It is in EDB's best interest to
sponsor the product that works best for them. Right now (maybe not for
everyone) that is clearly pl/java.

> That being said, pl-j is not as mature as pl/java, however I don't
> believe that is a valid reason for exclusion.
> Open source projects by their nature gain maturity by exposure.

It is a valid reason if it is going to be in core.

Sincerely,

Joshua D. Drake

--

=== The PostgreSQL Company: Command Prompt, Inc. ===
Sales/Support: +1.503.667.4564 || 24x7/Emergency: +1.800.492.2240
Providing the most comprehensive PostgreSQL solutions since 1997
http://www.commandprompt.com/

> When someone downloads the PostgreSQL server on Windows... we know
> they're probably going to be using ODBC... so we should ship it; but
> which one? How do we determine which one as a community?

Actually, this comes back to another scenario... There has been a
longstanding practice of letting distribution handlers deal with all of
this.

E.g; PostgreSQL is the core database. Anything external can be packaged
by someone else.

This is the whole reason mammothpostgresql.org exists.

> Eventually we need to evolve a little bit and tackle these types of
> issues; I don't think gborg or pgfoundry are the best places for
> high-profile, commonly used PostgreSQL drivers, PLs, or functions.

Well that would certainly depend on the goal of the project.

To me, it is not a big deal if we do or don't include PL/Java because we
will include it in mammothpostgresql.org.

What is a mistake to me, is including two projects that provide near
functionality.

Sincerely,

Joshua D. Drake

--

=== The PostgreSQL Company: Command Prompt, Inc. ===
Sales/Support: +1.503.667.4564 || 24x7/Emergency: +1.800.492.2240
Providing the most comprehensive PostgreSQL solutions since 1997
http://www.commandprompt.com/

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Tom Lane wrote:

> And in that light, the fact that PL/Java includes a huge whack of
> non-C code is very significant. *I* won't take responsibility for
> fixing PL/Java when I break it, because I don't know Java well enough.

That's the heart of the matter - PostgreSQL is a C project. All of the
other languages we use for PL/*, such as Perl, PHP, R, tcl, Python, etc.
are, at their heart, written in C. That's why I think comparing pl/java
to other pl languages is not apples to apples. Like Tom, I am also
uneasy about putting so much non-C code into the core.

- --
Greg Sabino Mullane greg(at)turnstep(dot)com
PGP Key: 0x14964AC8 200607131300
End Point Corporation
http://biglumber.com/x/web?pk=2529DF6AB8F79407E94445B4BC9B906714964AC8

-----BEGIN PGP SIGNATURE-----

iD8DBQFEtn00vJuQZxSWSsgRArG0AKC+PnCbgWWE2pT/8iMVCvnq0bhfSACg3rgF
qpcQ2OaB5K0KkiYzE3jp+50=
=E1rs
-----END PGP SIGNATURE-----

Csaba Nagy wrote:
> On Thu, 2006-07-13 at 15:29, Stephen Frost wrote:
>> It's not the PostgreSQL project's problem, that's true, but it certainly
>> becomes an issue for distributions. Java as a PL ends up being a pretty
>> odd case.. If there isn't anything in the PL code itself which forces a
>> dependency beyond gcj then it might be possible to distribute it. Also
>> allowing the PL to use a different JVM shouldn't be a problem so long as
>> nothing is distributed which depends on the alternate JVM. The GPL is
>> all about distribution and so I'm not sure that it would actually be a
>> problem for an end-user to use Sun's JVM with GPL'd Java code.
>
> Now I'm completely confused... what GPL code ? Is PL/Java licensed under
> the GPL ? Or what GPL code do you talk about ?

What was a mistake on my part. I was tired when I wrote the part about GPL.

Sincerely,

Joshua D. Drake

>
> The PL/Java code is likely only dependent on the JVM specification,
> which does not put any restriction on how you must license your code, so
> PL/Java can be licensed in any way the author wants, including BSD.
>
> The distribution part is also no problem as I see it, as only the build
> tools are not BSD, and they are available for free (including the Sun
> JDK) and they don't restrict what should be the license of the code you
> compile. This can only be a problem for purists like GPL zealots or
> perhaps debian, otherwise is not that hard to download and install the
> SUN JDK on a build machine... you don't need to distribute the JDK, only
> the runtime JVM, which you actually can do (including again the Sun
> runtime). So I can't see problems again from the packager point of
> view... except purists might put a separate pl/Java module in some
> "non-free" repository given the dependency on some "non-free" runtime...
>
> Cheers,
> Csaba.
>
>
>
> ---------------------------(end of broadcast)---------------------------
> TIP 1: if posting/reading through Usenet, please send an appropriate
> subscribe-nomail command to majordomo(at)postgresql(dot)org so that your
> message can get through to the mailing list cleanly
>

--

=== The PostgreSQL Company: Command Prompt, Inc. ===
Sales/Support: +1.503.667.4564 || 24x7/Emergency: +1.800.492.2240
Providing the most comprehensive PostgreSQL solutions since 1997
http://www.commandprompt.com/

> Aside from obviously the big issue of who maintains all the pgfoundry
> stuff, I also think that the PostgreSQL family would benefit from a
> distribution that is more "and the kitchen sink" style. I do not know
> exactly if Bizgres could be considered just that? Or maybe it could get
> promoted to be that?

Lukas, that is what www.mammothpostgresql.org is :)

Sincerely,

Joshua D. Drake

>
> What I mean is I think it makes absolute sense to keep a very stable,
> very well maintained core PostgreSQL distribution which is that anyone
> should base their distributions on. However I do think that PostgreSQL
> is missing out in getting new users aboard that are in the early stages
> of evalutation and simply only consider features that they get along
> with a default installation (mostly due to lack of better knowledge
> about places like pgfoundry). For these kinds of users it would make
> sense to provide a distro that has an extended feature list, while
> sacrificing maybe a tiny bit of stability because it adds modules that
> do not adhere to the same high level of maintaince as PostgreSQL core does.
>
> regards,
> Lukas
>
> ---------------------------(end of broadcast)---------------------------
> TIP 4: Have you searched our list archives?
>
> http://archives.postgresql.org
>

--

=== The PostgreSQL Company: Command Prompt, Inc. ===
Sales/Support: +1.503.667.4564 || 24x7/Emergency: +1.800.492.2240
Providing the most comprehensive PostgreSQL solutions since 1997
http://www.commandprompt.com/

> No matter what we want people to do, if someone wants PostgreSQL, they
> go to PostgreSQL's site, download PostgreSQL, and install PostgreSQL.
> The fact is, most people generally don't read the, "don't see it in
> the distribution, check out pgfoundry"-like text. Sure, people should
> read the docs, but most don't until they have to (which is long after
> getting the software). Do we even have anything in the actual manual
> that talks about gborg or pgfoundry?

Ahh no.

Most people who want PostgreSQL use the version supplied by their
vendor, unless it is Win32 in which case they download the installer
from PgFoundry.

Joshua D. Drake

--

=== The PostgreSQL Company: Command Prompt, Inc. ===
Sales/Support: +1.503.667.4564 || 24x7/Emergency: +1.800.492.2240
Providing the most comprehensive PostgreSQL solutions since 1997
http://www.commandprompt.com/

On 13-Jul-06, at 1:02 PM, Tom Lane wrote:

> Bruce Momjian <bruce(at)momjian(dot)us> writes:
>> I also cannot maintain Java, but we could do something like we do
>> with
>> WIN32, where outside folks submit patches to fix problems.
>
> However, a win32 failure breaks only the win32 buildfarm members ...
>
> Basically my point here is that I see no synergy from having PL/Java
> (or PL/J for that matter) in core. They can't share the same
> configure
> or build support as the rest of the code; the core developers don't
> feel
> qualified to maintain them; what's left?
>
> The argument in favor boils down to one and only one thing: bundling
> PL/Java will improve the visibility of PL/Java to people who won't go
> looking for it. That's fine, but ultimately that's a packaging
> argument
> not a development argument. The people who think PL/Java is an
> essential checklist item undoubtedly also think JDBC is an essential
> checklist item, but I'm not seeing any groundswell of support for
> putting JDBC back into core.

Well, if this discussion ends up in a java project getting into core
then there would be no reason whatsoever not to include JDBC. It's
certainly more germane to the project than the java pl's

> Instead we expect packagers (like the RPM
> set) to make JDBC available alongside the core postgres packages.
> That's how PL/Java ought to be handled, too, IMHO.
>
> In my own experience dealing with the Red Hat RPMs, it got a whole lot
> easier to package JDBC correctly once it wasn't mis-bundled into a
> basically non-Java source tarball, so I think that the packagers will
> also find that keeping it separate makes their lives easier.
>
> regards, tom lane
>

Regards,
Dave

Taking a step back here, I see two points in favor of including PL/Java or
something like it into the main CVS:

1. Build farm support

It seems that eventually one would like to have build farm support for many
things. I can see build farm support being useful for the ODBC driver or
Postgis, for instance. We need a better, more general solution for that.

2. Help with PL API changes

On the one hand, that seems great, but on the other hand, I see a lot of
people disqualifying themselves from touching PL/Java code in any significant
way because they don't know Java well enough. So I don't see this working in
practice. Or at least, it's quite doubtful that the convenience gained in
this area will outweigh any inconveniences coming from this move.

--
Peter Eisentraut
http://developer.postgresql.org/~petere/

"Jonah H. Harris" <jonah(dot)harris(at)gmail(dot)com> writes:
> I don't believe anyone has offered any suggestions or good
> alternatives other than what we have now; keeping high-profile
> projects like PL/Java on gborg/pgfoundry (which sucks IMHO).

This is really the whole issue right here: you want a monolithic "core"
distribution. I cannot begin to list the number of things wrong with
that approach, but suffice it to say that that's not the way PostgreSQL
is moving. We are getting larger and we need to cater to having lots of
sub-projects. A "core" distro containing everything that's reasonably
popular will eventually collapse of its own weight.

The right way to proceed is what was mentioned in another message: work
harder at educating packagers about which non-core projects are worth
including in their packages. I have to confess contributing to the
problem, as I'm not currently including eg. Slony in the Red Hat RPMs.
I certainly should be --- but "fixing" that by pushing Slony into the
core PG distro is not a solution.

regards, tom lane

> From: pgsql-hackers-owner(at)postgresql(dot)org
> [mailto:pgsql-hackers-owner(at)postgresql(dot)org] On Behalf Of
> Peter Eisentraut
>
> Taking a step back here, I see two points in favor of
> including PL/Java or
> something like it into the main CVS:
>
> 1. Build farm support
>
> It seems that eventually one would like to have build farm
> support for many
> things. I can see build farm support being useful for the
> ODBC driver or
> Postgis, for instance. We need a better, more general
> solution for that.

Does PL/Java really have to be in core to be tested in the build farm?
Could the build farm code be enhanced to test non-core stuff? (I like
the idea of a separate status 'light' for non-core.)

>
> 2. Help with PL API changes
>
> On the one hand, that seems great, but on the other hand, I
> see a lot of
> people disqualifying themselves from touching PL/Java code in
> any significant
> way because they don't know Java well enough. So I don't see
> this working in
> practice. Or at least, it's quite doubtful that the
> convenience gained in
> this area will outweigh any inconveniences coming from this move.
>

I think that if the buildfarm could alert us that there's a problem with
a PL when it happens, rather than discovering it way later, having the
code in the core repository is less critical.

Regarding the packagers who don't include non-core components that their
users might like, would a README.distros help? It could suggest good
things to include, where to find them, and tips for building. This could
also distinguish the mature packages on pgFoundry from the ones that are
not quite ready for prime time: when a package's maintainer(s) think
it's ready for production, they could submit a patch to the
README.distros that adds the package. (I'm not attached to the filename,
it just seemed less confusing than README.packagers.)

Regards,
Paul

Andrew Dunstan wrote:
> Tom Lane wrote:
>
>> Dave Cramer <pg(at)fastcrypt(dot)com> writes:
>>
>>
>>> The official JDBC driver is not being shipped with the project for
>>> exactly the same reasons, I fail to see any compelling reason to
>>> ship either java PL.
>>>
>>
>>
>>
>>> Unless we are going to create a complete distribution with a unified
>>> build, or at least a way to build each project (which I am in favour
>>> of) then we leave the server to itself and all other projects exist
>>> separately.
>>>

> One thing is for sure, we need to do some proselytizing among packagers
> to make sure they pick up more than just what is in core.

What packagers? Every packager I see (Ubuntu, Fedora, *BSD, even
Solaris) contain just about every conceivable package there is for
PostgreSQL :)

O.k. not every, but all of the really important stuff.

Joshua D. Drake

>
> cheers
>
> andrew
>
> ---------------------------(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
>

--

=== The PostgreSQL Company: Command Prompt, Inc. ===
Sales/Support: +1.503.667.4564 || 24x7/Emergency: +1.800.492.2240
Providing the most comprehensive PostgreSQL solutions since 1997
http://www.commandprompt.com/

On Thu, Jul 13, 2006 at 01:02:16PM -0400, Tom Lane wrote:
> PL/Java will improve the visibility of PL/Java to people who won't go
> looking for it. That's fine, but ultimately that's a packaging argument
> not a development argument. The people who think PL/Java is an
> essential checklist item undoubtedly also think JDBC is an essential
> checklist item, but I'm not seeing any groundswell of support for
> putting JDBC back into core. Instead we expect packagers (like the RPM
> set) to make JDBC available alongside the core postgres packages.
> That's how PL/Java ought to be handled, too, IMHO.

JDBC is different, in that it doesn't require the PostgreSQL core to
build. It's 100% native Java, and as such, I see benefit to it being
distributed separately.

This is why I was thinking that the problem is that the backend (SPI?)
API isn't exposed as native methods in the required languages. If just
the SPI API was exposed from the core to the languages, the
maintenance effort and size should be less, and the add-ons would not
require that they be built with the PostgreSQL core, making it easy to
integrate them after the fact.

If this is just crazy talk - please stop me.

Cheers,
mark

--
mark(at)mielke(dot)cc / markm(at)ncf(dot)ca / markm(at)nortel(dot)com __________________________
. . _ ._ . . .__ . . ._. .__ . . . .__ | Neighbourhood Coder
|\/| |_| |_| |/ |_ |\/| | |_ | |/ |_ |
| | | | | \ | \ |__ . | | .|. |__ |__ | \ |__ | Ottawa, Ontario, Canada

One ring to rule them all, one ring to find them, one ring to bring them all
and in the darkness bind them...

http://mark.mielke.cc/

* Joshua D. Drake (jd(at)commandprompt(dot)com) wrote:
> Csaba Nagy wrote:
> >On Thu, 2006-07-13 at 15:29, Stephen Frost wrote:
> >>It's not the PostgreSQL project's problem, that's true, but it certainly
> >>becomes an issue for distributions. Java as a PL ends up being a pretty
> >>odd case.. If there isn't anything in the PL code itself which forces a
> >>dependency beyond gcj then it might be possible to distribute it. Also
> >>allowing the PL to use a different JVM shouldn't be a problem so long as
> >>nothing is distributed which depends on the alternate JVM. The GPL is
> >>all about distribution and so I'm not sure that it would actually be a
> >>problem for an end-user to use Sun's JVM with GPL'd Java code.
> >
> >Now I'm completely confused... what GPL code ? Is PL/Java licensed under
> >the GPL ? Or what GPL code do you talk about ?
>
> What was a mistake on my part. I was tired when I wrote the part about GPL.

As for my part, I was referring to any GPL'd Java code being distributed
with a given distribution (ie: Debian), possibly running under PL/Java.
:)

Thanks,

Stephen

mark(at)mark(dot)mielke(dot)cc wrote:

>
>This is why I was thinking that the problem is that the backend (SPI?)
>API isn't exposed as native methods in the required languages. If just
>the SPI API was exposed from the core to the languages, the
>maintenance effort and size should be less, and the add-ons would not
>require that they be built with the PostgreSQL core, making it easy to
>integrate them after the fact.
>
>
>

The glue code needs much more than SPI. There is a lot of housekeeping
involved.

cheers

andrew

Bruce,

On 7/7/06 10:13 AM, "Bruce Momjian" <bruce(at)momjian(dot)us> 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.

On-disk bitmap index access method coming in about 1 week.

Multi-column index support is being worked more and will be disabled in the
patch first submitted, but could be enabled before code freeze.

There is a new directory for the access method and some changes to the
executor nodes that currently do bitmap operations, so brace for a large-ish
chunk of code.

Do we have a reviewer available? Volunteers?

- Luke

On Thu, Jul 13, 2006 at 01:26:30PM -0400, Tom Lane wrote:
> The right way to proceed is what was mentioned in another message: work
> harder at educating packagers about which non-core projects are worth
> including in their packages. I have to confess contributing to the
> problem, as I'm not currently including eg. Slony in the Red Hat RPMs.
> I certainly should be --- but "fixing" that by pushing Slony into the
> core PG distro is not a solution.

Indeed. Distributors are not going to go through pgfoundary and package
everything, there's just no point. I think it would be very useful to
dedicate a portion of the website to add-ons that are considered
worthwhile.

"considered worthwhile by who" becomes the big question then.
PgFoundary has a "Top Project Downloads" section. That gives a pretty
good indication of the things that should be advertised.

Have a nice day,
--
Martijn van Oosterhout <kleptog(at)svana(dot)org> http://svana.org/kleptog/
> From each according to his ability. To each according to his ability to litigate.

On 7/13/06, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> wrote:
> This is really the whole issue right here: you want a monolithic "core"
> distribution. I cannot begin to list the number of things wrong with
> that approach, but suffice it to say that that's not the way PostgreSQL
> is moving.

I'm not going to argue at all and will gladly second Josh's statement.
If the core doesn't want to include it, commercial companies
(EnterpriseDB, Command Prompt, ...) and consultants will continue to
do it for us. I mean, why should we make it easier for the end-user?
Especially when we know there are certain components that practically
every database user needs (ODBC, JDBC, etc.)

> We are getting larger and we need to cater to having lots of
> sub-projects. A "core" distro containing everything that's reasonably
> popular will eventually collapse of its own weight.

I don't think we should include everything, and I belive that
"collapse" is debatable. The important part is how the distro itself
is managed. One can easily create a "core" distribution which
includes PL/Java, ODBC, JDBC, etc. All of them don't have to reside
in the same CVS tree, but they can be built and released together. I
know because I've done it... and it's not that difficult. The hard
part is actually deciding what to include and what not to.

In general, we're talking about well established projects (PL/Java,
JDBC, ODBC, ...) with a great track record; not someone's personal
little proof-of-concept hack on pgfoundry.

Like I said, this discussion always seems to come up and we always go
back to saying "leave it to pgfoundry", "we'll promote pgfoundry",
"pgfoundry is the best place for it". Yet, I haven't really seen any
action to make pgfoundry any better or more well-known. I asked
before, is pgfoundry/gborg even mentioned in the documentation?

> The right way to proceed is what was mentioned in another
> message: work harder at educating packagers about which
> non-core projects are worth including in their packages.

OK, but who is going to do this? It certainly doesn't sound like any
of us want to spend the time educating packagers as we're either
working on our own things or for companies that already do package
PostgreSQL.

It just seems like we keep having lengthy recurring discussions that
seem to go nowhere. No solution is ever reached, we just keep the
status quo. Sure, risks either pay off or they don't, but it's just
as easy to die from stagnation as well.

I wish we could poll the actual end-users and see what their thoughts
are, because we're sort of thinking in a vacuum here (no pun
intended).

I can readily accept being wrong; but every once in a while, we just
need a little innovation.

--
Jonah H. Harris, Software Architect | phone: 732.331.1300
EnterpriseDB Corporation | fax: 732.331.1301
33 Wood Ave S, 2nd Floor | jharris(at)enterprisedb(dot)com
Iselin, New Jersey 08830 | http://www.enterprisedb.com/

mark(at)mark(dot)mielke(dot)cc writes:
> This is why I was thinking that the problem is that the backend (SPI?)
> API isn't exposed as native methods in the required languages. If just
> the SPI API was exposed from the core to the languages, the
> maintenance effort and size should be less, and the add-ons would not
> require that they be built with the PostgreSQL core, making it easy to
> integrate them after the fact.

It's not just SPI --- SPI for instance doesn't deal at all with the
problem of how you create a language call handler function. SPI was
never intended to be a "complete" API, but rather something easy to
use that covers most cases of C code needing to invoke SQL queries.
Code that's trying to offer features to SQL is entirely orthogonal
to what SPI is about.

I'm not real sure what a feature-complete API for language handlers
might look like, but it'd cover far more than SPI does. And this
really just begs the question: could we afford to promise a frozen
API that *is* feature-complete at that level? The changes we've made
recently that affected both core and PLs have mostly been things like
adding OUT parameter support, which certainly would have involved
changing a language handler API; or modifications to the system
catalogs, which I can't see a handler API masking; or changes to the
conventions for passing tuples as Datums, which again I doubt an API
would have successfully hidden.

It's an interesting idea to think about, but I think any solution
of this kind is a long way off, unless the internals of the backend
suddenly become a lot more stable than they have been in the past.

regards, tom lane

Tom Lane wrote:

>The right way to proceed is what was mentioned in another message: work
>harder at educating packagers about which non-core projects are worth
>including in their packages. I have to confess contributing to the
>problem, as I'm not currently including eg. Slony in the Red Hat RPMs.
>I certainly should be --- but "fixing" that by pushing Slony into the
>core PG distro is not a solution.
>
>
>

Well, there are other good reasons not to in the slony case.

But anyway, I was wondering if we could make life easier by providing a
script which would fetch some set of addon features, and make building
the whole lot together easy.

No doubt some people will not want to make choices, but I think we need
to, to some extent. I broadly agree with what Martijn has just said,
although I doubt that pgFoundry's Top Downloads section is much of a
guide. If we recommend something we need to be prepared to exerciase
some jusgement and have the courage of our convictions.

Personally, I would start with:

pl/java
pl/ruby
pl/php
jdbc driver
odbc driver
npgsql
python stuff (not sure which, as I don't use it)

The perl and php clients, and libpqxx would also be possibilities.

cheers

andrew

mark(at)mark(dot)mielke(dot)cc wrote:
> On Thu, Jul 13, 2006 at 01:02:16PM -0400, Tom Lane wrote:
>> PL/Java will improve the visibility of PL/Java to people who won't go
>> looking for it. That's fine, but ultimately that's a packaging argument
>> not a development argument. The people who think PL/Java is an
>> essential checklist item undoubtedly also think JDBC is an essential
>> checklist item, but I'm not seeing any groundswell of support for
>> putting JDBC back into core. Instead we expect packagers (like the RPM
>> set) to make JDBC available alongside the core postgres packages.
>> That's how PL/Java ought to be handled, too, IMHO.
>
> JDBC is different, in that it doesn't require the PostgreSQL core to
> build. It's 100% native Java, and as such, I see benefit to it being
> distributed separately.

PLJava does not need PostgreSQL core to build either. It needs:

pgxs + Postgresql libs + PostgreSQL headers

In essence the PostgreSQL SDK.

If I read what Thomas wrote (late) last night correctly.

Sincerely,

Joshua D. Drake

--

=== The PostgreSQL Company: Command Prompt, Inc. ===
Sales/Support: +1.503.667.4564 || 24x7/Emergency: +1.800.492.2240
Providing the most comprehensive PostgreSQL solutions since 1997
http://www.commandprompt.com/

On Thu, 13 Jul 2006, Jonah H. Harris wrote:

> I don't believe anyone has offered any suggestions or good alternatives
> other than what we have now; keeping high-profile projects like PL/Java
> on gborg/pgfoundry (which sucks IMHO).

Why?

What is being discussed here is *purely* a packaging issue ... how many
actually download the postgresql tar ball directly, vs downloading RPMs,
or installing from FreeBSD ports, or Solaris packages, or ... ?

Using pl/Java as an example ... just went to Google, searched for
pl<space>java, and gborg comes up as the first response, so finding it
isn't difficult ...

But, I can't find anything there to download ... just a pointer to a Wiki,
which, I'm sorry, would definitely not be my first thought to go look at
for a downloads ...

So, let's try ftp ...

ftp.postgresql.org:/pub/projects/gborg/pljava/stable:

Nothing there newer then November 2005:

ftp> ls -lt
227 Entering Passive Mode (66,98,251,159,248,251)
150 Opening ASCII mode data connection for /bin/ls.
total 23026
-rw-r--r-- 1 80 1009 206134 Nov 20 2005 pljava-src-1.2.0.tar.gz
-rw-r--r-- 1 80 1009 522895 Nov 20 2005 pljava-i686-pc-mingw32-pg8.1-1.2.0.tar.gz
-rw-r--r-- 1 80 1009 522955 Nov 20 2005 pljava-i686-pc-mingw32-pg8.0-1.2.0.tar.gz
-rw-r--r-- 1 80 1009 421717 Nov 20 2005 pljava-i686-pc-linux-gnu-pg8.1-1.2.0.tar.gz
-rw-r--r-- 1 80 1009 421999 Nov 20 2005 pljava-i686-pc-linux-gnu-pg8.0-1.2.0.tar.gz

so, if there is a newer version (I actually eventually went to the wiki,
so know there is a 1.3.0), its not taking advantage of the PostgreSQL file
distribution network that has been developed over the years ...

'k, go back and check Google, the top 5 listings, in order:

gborg x 2
pl-j
pgfoundry
pljava wiki

so, if using google, the first place most ppl will go to look for
informatino is the one place you say "sucks" ... gborg ... second choice
would be the other place you say "sucks" ... pgfoundry ... eventually,
giving up on those two, they'd maybe try the wiki, *but*, only because the
project maintainer hasn't been uploading files to gborg/pgfoundry, not
because gborg/pgfoundry isn't found in search engines ...

----
Marc G. Fournier Hub.Org Networking Services (http://www.hub.org)
Email . scrappy(at)hub(dot)org MSN . scrappy(at)hub(dot)org
Yahoo . yscrappy Skype: hub.org ICQ . 7615664

On Thu, 13 Jul 2006, Jonah H. Harris wrote:

> On 7/13/06, Lukas Smith wrote:
>> However I do think that PostgreSQL is missing out in
>> getting new users aboard that are in the early stages
>> of evalutation and simply only consider features that
>> they get along with a default installation (mostly due
>> to lack of better knowledge about places like pgfoundry).
>
> This is my point exactly. As with many things, we keep skirting the
> real issue by going with an "improve the smaller component" approach
> such as "promote pgfoundry more". I have never seen this approach
> work, but maybe someone has an example of another OSS project that has
> successfully excluded major components like this?

Major component for whom exactly? What %age of PostgreSQL users are using
pl/Java? Are using Java, period?

There is only one *major component* and that is the RDBMS itself ...
everything else is an add on specific to each end users requirements ...
in all of my years of hosting PostgreSQL-backed web sites, I've *never*
had a request for a PL/J* ... lots for JDBC, mind you, just never for the
PLs ...

So, do you have some sort of #s as to why pl/Java is such a 'major
component'? I'd see pl/Perl and pl/PHP as been alot more major ...

> My question is, what is the packagers' stance on this topic? It seems
> like more work for them than for anyone else.

Why more work for them? CommandPrompt developed pl/PHP in such a way that
it doesn't require the PostgreSQL source code at all ... so, a packager
coudl go out, get a binary (rpm?) distro of PostgreSQL, install that and
then build their pl/PHP package, without ever having to touch the
postgresql source code ...

----
Marc G. Fournier Hub.Org Networking Services (http://www.hub.org)
Email . scrappy(at)hub(dot)org MSN . scrappy(at)hub(dot)org
Yahoo . yscrappy Skype: hub.org ICQ . 7615664

On 7/13/06, Marc G. Fournier <scrappy(at)postgresql(dot)org> wrote:
> Why?

Because, the fact is that it's a PITA and many people don't even go
far enough to look. If major components of PostgreSQL were included
in the core, it would make it much easier for people; especially those
familiar with commercial-class database systems.

> What is being discussed here is *purely* a packaging issue

Pretty much.

> Using pl/Java as an example ... just went to Google, searched for
> pl<space>java, and gborg comes up as the first response, so finding it
> isn't difficult ...

Never said it was... but then again, you already know about it.

> But, I can't find anything there to download ... just a pointer to a Wiki,
> which, I'm sorry, would definitely not be my first thought to go look at
> for a downloads ...

Hmm, yes... just saw that and it is a bit odd. Thomas, I like the
layout of the Wiki... but could we move the project files to pgfoundry
for hosting and set the project's home page as the wiki?

--
Jonah H. Harris, Software Architect | phone: 732.331.1300
EnterpriseDB Corporation | fax: 732.331.1301
33 Wood Ave S, 2nd Floor | jharris(at)enterprisedb(dot)com
Iselin, New Jersey 08830 | http://www.enterprisedb.com/

On Thu, 13 Jul 2006, Jonah H. Harris wrote:

> Aside from obviously the big issue of who maintains all the pgfoundry
> stuff, I also think that the PostgreSQL family would benefit from a
> distribution that is more "and the kitchen sink" style.

This has been suggested before ... nobody seems to want to 'run with
it'/coordinate it though ... maybe that, in itself, is argument enough
against doing it, only a small number of ppl *really* care/want it, and
those ones aren't willing to put forth the energy required to do it ...

----
Marc G. Fournier Hub.Org Networking Services (http://www.hub.org)
Email . scrappy(at)hub(dot)org MSN . scrappy(at)hub(dot)org
Yahoo . yscrappy Skype: hub.org ICQ . 7615664

> I don't think we should include everything, and I belive that
> "collapse" is debatable. The important part is how the distro itself
> is managed. One can easily create a "core" distribution which
> includes PL/Java, ODBC, JDBC, etc. All of them don't have to reside
> in the same CVS tree, but they can be built and released together. I
> know because I've done it... and it's not that difficult. The hard
> part is actually deciding what to include and what not to.

And people already do this...

The Win32 installer
mammothpostgresql.org (which is 100% FOSS btw)
Ubuntu :)

So why put the load on the Core distro?

> In general, we're talking about well established projects (PL/Java,
> JDBC, ODBC, ...) with a great track record; not someone's personal
> little proof-of-concept hack on pgfoundry.

Well define great track record? Of the three you mention, two of them
are debatable.

PL/java although from what I can tell is stable but it is still young.

ODBC is a constant problem, I didn't even realize what level of problem
ODBC could be until we wrote our own driver (READ: I am not blaming the
ODBC team)

> Like I said, this discussion always seems to come up and we always go
> back to saying "leave it to pgfoundry", "we'll promote pgfoundry",
> "pgfoundry is the best place for it". Yet, I haven't really seen any
> action to make pgfoundry any better or more well-known. I asked
> before, is pgfoundry/gborg even mentioned in the documentation?

It is on the website and in the documentation. Albeit not as prominent
as it could be.

And to be frank, the amount of time any of us has spent on this thread
could have easily been used to improve the documentation on this
particular subject.

>> The right way to proceed is what was mentioned in another
>> message: work harder at educating packagers about which
>> non-core projects are worth including in their packages.
>
> OK, but who is going to do this? It certainly doesn't sound like any
> of us want to spend the time educating packagers as we're either
> working on our own things or for companies that already do package
> PostgreSQL.

Well honestly this seems like a no-op. The distributions that really
matter, are going to have packagers that know what is out there.
Ubuntu/Debian and FreeBSD come to mind first.

> It just seems like we keep having lengthy recurring discussions that
> seem to go nowhere. No solution is ever reached, we just keep the
> status quo. Sure, risks either pay off or they don't, but it's just
> as easy to die from stagnation as well.

Haha :) Welcome to FOSS development man :). It is 75% discussions that
go nowhere, 20% percent that get somewhere (noone actually knows where)
and 5% that gets done :)

> I wish we could poll the actual end-users and see what their thoughts
> are, because we're sort of thinking in a vacuum here (no pun
> intended).

Well my users expect me to provide their tools, not the community. In
fact that is one of the most oft questions I get asked: "If we want to
help PostgreSQL, will you handle it for us".

>
> I can readily accept being wrong; but every once in a while, we just
> need a little innovation.
>

I don't think innovation is the word your looking for, progress maybe?

The problem is, progress is determined by arbitrary value to which
everyone has an opinion.

I mean heck... I still think we should introduce new features into back
branches as long as it doesn't require an initdb but most (including my
own developers) don't agree with me.

Sincerely,

Joshua D. Drake

--

=== The PostgreSQL Company: Command Prompt, Inc. ===
Sales/Support: +1.503.667.4564 || 24x7/Emergency: +1.800.492.2240
Providing the most comprehensive PostgreSQL solutions since 1997
http://www.commandprompt.com/

On Thu, 13 Jul 2006, Jonah H. Harris wrote:

> On 7/13/06, Dave Cramer <pg(at)fastcrypt(dot)com> wrote:
>> The official JDBC driver is not being shipped with the project for
>> exactly the same reasons, I fail to see any compelling reason to ship
>> either java PL.
>
> IMHO, we should be shipping the JDBC driver... but that's another
> matter entirely.

Again, that goes to your 'kitchen sink distribution' ... its been
suggested many times before, nobody cared enough to run with the idea and
do something about it ... do you?

> When someone downloads the PostgreSQL server on Windows... we know
> they're probably going to be using ODBC... so we should ship it; but
> which one? How do we determine which one as a community?

that's a packaging issue ... the Windows Installer can (does?) pull that
in as part of its install, or, at least, packaging stage, as it does other
things ...

> Eventually we need to evolve a little bit and tackle these types of
> issues; I don't think gborg or pgfoundry are the best places for
> high-profile, commonly used PostgreSQL drivers, PLs, or functions.

Commonly used by whom? a pl/PHP user is most likely not going to ever use
pl/Perl, or any other pl ... so, which are "commonly used" and which are
used by a "small set of ppl"?

----
Marc G. Fournier Hub.Org Networking Services (http://www.hub.org)
Email . scrappy(at)hub(dot)org MSN . scrappy(at)hub(dot)org
Yahoo . yscrappy Skype: hub.org ICQ . 7615664

On Thu, 13 Jul 2006, Rod Taylor wrote:

> A slight restructuring of the FTP tree should probably be made. It's
> currently very easy to find the main pgsql, pgadmin and odbc components.
> Finding pl/java (what the heck is that gborg or pgfoundry project?) is
> pretty difficult.

The gborg vs pgfoundry issue is being worked on, albeit slowly ... gborg
is being 'sucked into' pgfoundry, but with OSCON and the Conference, and
summer holidays, things have slowed down a bit ....

----
Marc G. Fournier Hub.Org Networking Services (http://www.hub.org)
Email . scrappy(at)hub(dot)org MSN . scrappy(at)hub(dot)org
Yahoo . yscrappy Skype: hub.org ICQ . 7615664

On Thu, 13 Jul 2006, Joshua D. Drake wrote:

>
>> I don't think we should include everything, and I belive that
>> "collapse" is debatable. The important part is how the distro itself
>> is managed. One can easily create a "core" distribution which
>> includes PL/Java, ODBC, JDBC, etc. All of them don't have to reside
>> in the same CVS tree, but they can be built and released together. I
>> know because I've done it... and it's not that difficult. The hard
>> part is actually deciding what to include and what not to.
>
>
> And people already do this...
>
> The Win32 installer
> mammothpostgresql.org (which is 100% FOSS btw)
> Ubuntu :)
>
> So why put the load on the Core distro?

Agreed ... but, maybe on our FTP/download pages, we should add a link for
'Distributions', that would include mammothpostgresql.org and Ubuntu? so
that ppl knew about them? We do it for support related stuff ...

----
Marc G. Fournier Hub.Org Networking Services (http://www.hub.org)
Email . scrappy(at)hub(dot)org MSN . scrappy(at)hub(dot)org
Yahoo . yscrappy Skype: hub.org ICQ . 7615664

On 7/13/06, Marc G. Fournier <scrappy(at)postgresql(dot)org> wrote:
> Major component for whom exactly? What %age of PostgreSQL
> users are using pl/Java? Are using Java, period?

Got me, but I don't think you have the facts to dispute it either. As
I said, we're discussing this in a vacuum.

> There is only one *major component* and that is the RDBMS itself ...
> everything else is an add on specific to each end users requirements

Hmm, connecting to the database is an end-user requirement. That's
why every database vendor in the world has an ODBC and JDBC driver...
and why most of them ship it with the server?

> in all of my years of hosting PostgreSQL-backed web sites, I've *never*
> had a request for a PL/J* ... lots for JDBC, mind you, just never for the
> PLs ...

Interesting

> Why more work for them? CommandPrompt developed pl/PHP
> in such a way that it doesn't require the PostgreSQL source code
> at all ... so, a packager coudl go out, get a binary (rpm?) distro
> of PostgreSQL, install that and then build their pl/PHP package,
> without ever having to touch the postgresql source code ...

Again, you and I are PostgreSQL people. Arguing with me about how
easy it is to do X and Y is pointless. I'm talking about someone new
to PostgreSQL... AFAICS, we have *never* been looking to help them
which I believe is another reason for lesser adoption.

I'm not trying to be pessimistic, but this reminds me of that Ubergeek
Flash animation with the Linux SuperVillian
(http://www.ubergeek.tv/article.php?pid=54):

Excerpt (regarding Linux):
You've got to config it. And then you have to write some shell
scripts. Update your RPMs. You have to partition your drives. And
patch your kernel. Compile your binaries. Check your version
dependencies. Probably do that once or twice. It's just so easy. And
so simple. I don't know why everyone doesn't run Linux. Thank God
they don't, or then they would all be supervillains, wouldn't they?
Heh heh.

Sounds kinda like our discussions:
You've got to download it. And then you have to go check the website.
Download some drivers and PLs. You have to check your version
dependencies. Compile your binaries and/or install them. Probably do
that once or twice. It's just so easy. And so simple. I don't know
why everyone doesn't use PostgreSQL. Thank God they don't, or then
they would all be supervillains, wouldn't they? Heh heh.

Look, we all love PostgreSQL and we all want to see it do better;
otherwise we wouldn't be here. As a community, we all have some
influence in the project as well as a stake in what happens.

Rather than geting all defensive, we need to find out what people who
are using PostgreSQL want so we can make a distribution and/or
recommendation to packagers. Again, the arguments made here only
apply to current users, when we *should* be thinking about what new
users as well as current users would benefit from.

--
Jonah H. Harris, Software Architect | phone: 732.331.1300
EnterpriseDB Corporation | fax: 732.331.1301
33 Wood Ave S, 2nd Floor | jharris(at)enterprisedb(dot)com
Iselin, New Jersey 08830 | http://www.enterprisedb.com/

On 7/13/06, Marc G. Fournier <scrappy(at)postgresql(dot)org> wrote:
> Again, that goes to your 'kitchen sink distribution' ... its been
> suggested many times before, nobody cared enough to run
> with the idea and do something about it ... do you?

I certainly care, but I don't have the time. Which, I know, is the
case with most of us.

--
Jonah H. Harris, Software Architect | phone: 732.331.1300
EnterpriseDB Corporation | fax: 732.331.1301
33 Wood Ave S, 2nd Floor | jharris(at)enterprisedb(dot)com
Iselin, New Jersey 08830 | http://www.enterprisedb.com/

On Thu, 13 Jul 2006, Jonah H. Harris wrote:

> Sounds kinda like our discussions:
> You've got to download it. And then you have to go check the website.
> Download some drivers and PLs. You have to check your version
> dependencies. Compile your binaries and/or install them. Probably do
> that once or twice. It's just so easy. And so simple. I don't know
> why everyone doesn't use PostgreSQL. Thank God they don't, or then
> they would all be supervillains, wouldn't they? Heh heh.

'k, but, again, this comes to someone (you?) stepping forward and
dedicating the time/energy to developing a 'mega distribution', and being
willing to provide support for it ... see, as soon as you incorporate all
of this as one big package, then ppl will turn to the maintainer of that
'mega package' for their support needs, cause they won't know that pl/Java
is maintained by Thomas Hallgren, or that pl/PHP is maintained by
CommandPrompt, or that ...

But, again, its not a *core* distribution issue, it is a packaging issue
...

And note that I didn't include 'resources' in the above 'time/energy', as
you *can* use pgfoundry for that ...

Heck, why not building a Unix Installer like the Windows one, bring up a
menu with a list of options to install, and pull in what is needed,
instead of forcing it all on someone? Neat thing about that: you could
then maintain statistics on what ppl are actually downloading ...

But, as JD pointed out earlier ... there is mammothpostgresql.org already,
which is apparently FOSS, so instead of "yet another distribution" maybe
look into extending that, add an Installation interface over top of it (if
it doesn't already exist), etc ... ?

----
Marc G. Fournier Hub.Org Networking Services (http://www.hub.org)
Email . scrappy(at)hub(dot)org MSN . scrappy(at)hub(dot)org
Yahoo . yscrappy Skype: hub.org ICQ . 7615664

On Thu, 13 Jul 2006, Joshua D. Drake wrote:

>
>> Aside from obviously the big issue of who maintains all the pgfoundry
>> stuff, I also think that the PostgreSQL family would benefit from a
>> distribution that is more "and the kitchen sink" style. I do not know
>> exactly if Bizgres could be considered just that? Or maybe it could get
>> promoted to be that?
>
> Lukas, that is what www.mammothpostgresql.org is :)

Then *it* needs to be promoted more, since this is actually the first I'd
heard of it :(

----
Marc G. Fournier Hub.Org Networking Services (http://www.hub.org)
Email . scrappy(at)hub(dot)org MSN . scrappy(at)hub(dot)org
Yahoo . yscrappy Skype: hub.org ICQ . 7615664

"Jonah H. Harris" <jonah(dot)harris(at)gmail(dot)com> writes:
> On 7/13/06, Marc G. Fournier <scrappy(at)postgresql(dot)org> wrote:
>> Why?

> Because, the fact is that it's a PITA and many people don't even go
> far enough to look. If major components of PostgreSQL were included
> in the core, it would make it much easier for people; especially those
> familiar with commercial-class database systems.

No, the correct way to say that is "if major components were included in
the readily-available distributions of Postgres" then newbies would find
it easier to find them. That doesn't lead to concluding that we should
redefine "core" as "everything that's popular". These days I don't
believe that many newbies download and compile the core PG source
distribution --- newbies are using the Windows installer or pre-packaged
Linux distributions, and so the right answer is to make sure that those
packagers provide all the important add-ons nearby to the core packages.

For those who are actually downloading stuff directly from
http://www.postgresql.org/download/, that page already does list most
of the add-ons that have been mentioned in this thread. Perhaps we need
to adjust the wording to make it clearer that you probably want some of
them. One really trivial change is that the second sentence says "full
package" where it ought to say "core package" --- we should consistently
reinforce the idea that you're getting a database core, not everything
that you might want to go with it.

regards, tom lane

On 7/13/06, Marc G. Fournier <scrappy(at)postgresql(dot)org> wrote:
> 'k, but, again, this comes to someone (you?) stepping forward and
> dedicating the time/energy to developing a 'mega distribution', and being
> willing to provide support for it

True. Then maybe we should just all work together to make a
distribution suggestion to packagers of the major components and their
versions. That way the packagers at least have a good idea of what we
believe is "good-to-go" with X version of PostgreSQL.

> Heck, why not building a Unix Installer like the Windows one, bring up a
> menu with a list of options to install, and pull in what is needed,
> instead of forcing it all on someone? Neat thing about that: you could
> then maintain statistics on what ppl are actually downloading ...

Yes, I very much like this idea.

> But, as JD pointed out earlier ... there is mammothpostgresql.org already,
> which is apparently FOSS, so instead of "yet another distribution" maybe
> look into extending that, add an Installation interface over top of it (if
> it doesn't already exist), etc ... ?

Not to be too "business" about it, but a PostgreSQL community
distribution should IMHO, be vendor neutral. If the installer were
vendor-branding-free, I'd be game.

--
Jonah H. Harris, Software Architect | phone: 732.331.1300
EnterpriseDB Corporation | fax: 732.331.1301
33 Wood Ave S, 2nd Floor | jharris(at)enterprisedb(dot)com
Iselin, New Jersey 08830 | http://www.enterprisedb.com/

On Thu, 13 Jul 2006, Joshua D. Drake wrote:

>
>> No matter what we want people to do, if someone wants PostgreSQL, they
>> go to PostgreSQL's site, download PostgreSQL, and install PostgreSQL.
>> The fact is, most people generally don't read the, "don't see it in
>> the distribution, check out pgfoundry"-like text. Sure, people should
>> read the docs, but most don't until they have to (which is long after
>> getting the software). Do we even have anything in the actual manual
>> that talks about gborg or pgfoundry?
>
> Ahh no.
>
> Most people who want PostgreSQL use the version supplied by their vendor,
> unless it is Win32 in which case they download the installer from PgFoundry.

Agreed ... I never download from ftp unless I need an older version then
is provided in FreeBSD ports ... and I have a few clients that won't even
*touch* the source code, but will only install the version that their
OS vendor provides, for support reasons ...

----
Marc G. Fournier Hub.Org Networking Services (http://www.hub.org)
Email . scrappy(at)hub(dot)org MSN . scrappy(at)hub(dot)org
Yahoo . yscrappy Skype: hub.org ICQ . 7615664

On 7/13/06, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> wrote:
> No, the correct way to say that is "if major components were included in
> the readily-available distributions of Postgres" then newbies would find
> it easier to find them.

OK, I agree. Damn semantics :)

> That doesn't lead to concluding that we should redefine "core"
> as "everything that's popular".

Alright, but I believe we should at least work together when planning
a release to make a set recommendation to packagers.

> These days I don't believe that many newbies download and
> compile the core PG source distribution

Totally agreed. I have been meaning that our packages (non-src)
should have common tools with them.

> For those who are actually downloading stuff directly from
> http://www.postgresql.org/download/, that page already does list most
> of the add-ons that have been mentioned in this thread.
> Perhaps we need to adjust the wording to make it clearer ...

Yes, that would probably help some.

> One really trivial change is that the second sentence says "full
> package" where it ought to say "core package" --- we should consistently
> reinforce the idea that you're getting a database core, not everything
> that you might want to go with it.

Agreed.

--
Jonah H. Harris, Software Architect | phone: 732.331.1300
EnterpriseDB Corporation | fax: 732.331.1301
33 Wood Ave S, 2nd Floor | jharris(at)enterprisedb(dot)com
Iselin, New Jersey 08830 | http://www.enterprisedb.com/

kleptog(at)svana(dot)org (Martijn van Oosterhout) writes:
> On Thu, Jul 13, 2006 at 01:26:30PM -0400, Tom Lane wrote:
>> The right way to proceed is what was mentioned in another message:
>> work harder at educating packagers about which non-core projects
>> are worth including in their packages. I have to confess
>> contributing to the problem, as I'm not currently including
>> eg. Slony in the Red Hat RPMs. I certainly should be --- but
>> "fixing" that by pushing Slony into the core PG distro is not a
>> solution.
>
> Indeed. Distributors are not going to go through pgfoundary and
> package everything, there's just no point. I think it would be very
> useful to dedicate a portion of the website to add-ons that are
> considered worthwhile.

If there were enough chunks of it that were buildable using pgxs or
similar such that they could pretty readily script up...

for project in `echo $LIST`; do
cd $DOWNLOADS
wget http://downloads.pgfoundry.org/${project}/${project}-latest.tar.bz2
cd $BUILDHOME
mkdir $${project}
cd $${project}
tar xfvj $DOWNLOADS/${project}-latest.tar.bz2
cd *
./configure --pgxs-options --path=/usr --rpm-deteriorata
make install
run-rpm-file-collector $${project}
done

The folks running Perl and Python repositories have gotten the
"toolage" together so that you can pull CPAN packages and very nearly
turn them into RPM packages.

If we have an interestingly large set of packages at pgFoundry that
are "that RPMable," then they *will* come.
--
let name="cbbrowne" and tld="cbbrowne.com" in name ^ "@" ^ tld;;
http://cbbrowne.com/info/oses.html
Rules of the Evil Overlord #98. "If an attractive young couple enters
my realm, I will carefully monitor their activities. If I find they
are happy and affectionate, I will ignore them. However if
circumstance have forced them together against their will and they
spend all their time bickering and criticizing each other except
during the intermittent occasions when they are saving each others'
lives at which point there are hints of sexual tension, I will
immediately order their execution." <http://www.eviloverlord.com/>

> Major component for whom exactly? What %age of PostgreSQL users are
> using pl/Java? Are using Java, period?
>
> There is only one *major component* and that is the RDBMS itself ...
> everything else is an add on specific to each end users requirements ...
> in all of my years of hosting PostgreSQL-backed web sites, I've *never*
> had a request for a PL/J* ... lots for JDBC, mind you, just never for
> the PLs ...
>
> So, do you have some sort of #s as to why pl/Java is such a 'major
> component'? I'd see pl/Perl and pl/PHP as been alot more major ...

I know I am going to regret this but:

pl/Java is a MAJOR component. In one place. The Enterprise.

Otherwise it really isn't. A spot poll of businesses will show quite
readily that most are running, PHP, Perl, Ruby, Python... and
unfortunately VB.

However, for the most part NOT if they are an Enterprise.

It is also a major component in our battle against the big red O.

However, all of this argument is moot.

The only argument that really matters in this discussion is the one that
Tom brought up.

>> My question is, what is the packagers' stance on this topic? It seems
>> like more work for them than for anyone else.
>
> Why more work for them? CommandPrompt developed pl/PHP in such a way
> that it doesn't require the PostgreSQL source code at all ... so, a
> packager coudl go out, get a binary (rpm?) distro of PostgreSQL, install
> that and then build their pl/PHP package, without ever having to touch
> the postgresql source code ...

Yes and my understanding is that PLjava can do the same.

Sincerely,

Joshua D. Drake

>
> ----
> Marc G. Fournier Hub.Org Networking Services (http://www.hub.org)
> Email . scrappy(at)hub(dot)org MSN . scrappy(at)hub(dot)org
> Yahoo . yscrappy Skype: hub.org ICQ . 7615664
>
> ---------------------------(end of broadcast)---------------------------
> TIP 1: if posting/reading through Usenet, please send an appropriate
> subscribe-nomail command to majordomo(at)postgresql(dot)org so that your
> message can get through to the mailing list cleanly
>

--

=== The PostgreSQL Company: Command Prompt, Inc. ===
Sales/Support: +1.503.667.4564 || 24x7/Emergency: +1.800.492.2240
Providing the most comprehensive PostgreSQL solutions since 1997
http://www.commandprompt.com/