Hi,
Tom Lane írta:
Zoltan Boszormenyi <[EMAIL PROTECTED]> writes:
I am working on adding a new column contraint,
namely the GENERATED [ALWAYS | BY DEFAULT ] AS
[ IDENTITY ( sequence_options ) | ( expression )]
Doesn't this still have the issue that we're taking over spec-defined
synta
Zoltan Boszormenyi <[EMAIL PROTECTED]> writes:
> I am working on adding a new column contraint,
> namely the GENERATED [ALWAYS | BY DEFAULT ] AS
> [ IDENTITY ( sequence_options ) | ( expression )]
Doesn't this still have the issue that we're taking over spec-defined
syntax to represent behavior th
Hi,
Bruce Momjian írta:
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
Ühel kenal päeval, K, 2006-07-12 kell 17:48, kirjutas Thomas Hallgren:
> 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 m
Tom Lane wrote:
> Andrew Dunstan <[EMAIL PROTECTED]> writes:
> > Quite so. That's why buildfarm for pl/java will be important when I can
> > get it done.
>
> +1 --- the important point about an arrangement like that is that it'll
> be clear from the buildfarm results that pljava is broken, and no
Andrew Dunstan <[EMAIL PROTECTED]> writes:
> Quite so. That's why buildfarm for pl/java will be important when I can
> get it done.
+1 --- the important point about an arrangement like that is that it'll
be clear from the buildfarm results that pljava is broken, and not the
whole system. (Contra
Marc G. Fournier wrote:
On Thu, 13 Jul 2006, Andrew Dunstan wrote:
Marc G. Fournier wrote:
Second, its assuming that Thomas, or any other pl/java developer,
*isn't* going to watching for any changes to the API fairly closely,
considering they know it does happen, and, therefore, won't make
On Thu, 13 Jul 2006, Jonah H. Harris wrote:
On 7/13/06, Tom Lane <[EMAIL PROTECTED]> 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
On Thu, 13 Jul 2006, Andrew Dunstan wrote:
Marc G. Fournier wrote:
Second, its assuming that Thomas, or any other pl/java developer, *isn't*
going to watching for any changes to the API fairly closely, considering
they know it does happen, and, therefore, won't make a change to their
develo
On Thu, 13 Jul 2006, Andrew Dunstan wrote:
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 curre
Marc G. Fournier wrote:
Second, its assuming that Thomas, or any other pl/java developer,
*isn't* going to watching for any changes to the API fairly closely,
considering they know it does happen, and, therefore, won't make a
change to their development code to accommodate that when the time
On Fri, 14 Jul 2006, Satoshi Nagayasu wrote:
However, several extensions, such as pl/java, strongly depend on the
backend internal functions and arguments. If they are suddenly changed,
the extension XX couldn't be compiled anymore, and the users will waste
their time.
There are several flaw
On Fri, 14 Jul 2006, Thomas Hallgren wrote:
Marc G. Fournier wrote:
But Thomas, that means finding someone willing to do the work to build the
port ... :)
PL/java should be very easy to port. In fact, I'm not sure any specific
porting is needed. There might be some minor makefile quirk (that
Hi,
On Thu, 2006-07-13 at 15:33 -0400, Chris Browne wrote:
> If we have an interestingly large set of packages at pgFoundry that
> are "that RPMable," then they *will* come.
Personally I am interested in building all RPMable PostgreSQL related
projects. Currently I do packaging for PostgreSQL, p
Marc G. Fournier wrote:
But Thomas, that means finding someone willing to do the work to build
the port ... :)
PL/java should be very easy to port. In fact, I'm not sure any specific porting is needed.
There might be some minor makefile quirk (that is what has bitten me on other platforms). I
On Thu, 13 Jul 2006, Chris Browne wrote:
kleptog@svana.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 in
Hey JD, I notice that we don't have a port for plphp either ... if one
of your guys wants to create one, I can get it committed ...
DarcyB is supposed to be handling that :)
Joshua D. Drake
Marc G. Fournier Hub.Org Networking Services (http://www.hub.org)
Email . [EMAIL PRO
On Fri, 14 Jul 2006, Thomas Hallgren wrote:
Marc G. Fournier wrote:
I'm confused here ... "has been on gborg for several weeks, but only
available through the wiki" ...
On: http://gborg.postgresql.org/project/pljava/projdisplay.php ... I can't
find any way of downloading 1.3.0 (or, older r
Kris Jurka wrote:
>
>
> On Thu, 13 Jul 2006, Tom Lane wrote:
>
>> 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
On Thu, 13 Jul 2006, D'Arcy J.M. Cain wrote:
On Thu, 13 Jul 2006 19:54:19 -0300 (ADT)
"Marc G. Fournier" <[EMAIL PROTECTED]> wrote:
Well NetBSD doesn't offer pl/java now so I'm not sure what point you are
trying to make. Sure it would be nice if every OS provided every version of
every package
Marc G. Fournier wrote:
... the only reason 'NetBSD doesn't offer pl/java now' is because nobody
a) is using it under NetBSD or b) submitted a port to their system
Should be fairly straight forward if the PostgreSQL SDK and gcj 4.0 or later is installed.
Download the PL/Java source tarball, ma
On Thu, 13 Jul 2006 19:54:19 -0300 (ADT)
"Marc G. Fournier" <[EMAIL PROTECTED]> wrote:
> > Well NetBSD doesn't offer pl/java now so I'm not sure what point you are
> > trying to make. Sure it would be nice if every OS provided every version
> > of
> > every package, but when they don't what are
Jonah H. Harris wrote:
> 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.
Which oper
Marc G. Fournier wrote:
I'm confused here ... "has been on gborg for several weeks, but only
available through the wiki" ...
On: http://gborg.postgresql.org/project/pljava/projdisplay.php ... I
can't find any way of downloading 1.3.0 (or, older releases even) ...
have you been uploading, bu
On Fri, 14 Jul 2006, Thomas Hallgren wrote:
Marc G. Fournier wrote:
How would I go about taking advantage of that? And who did the 1.2.0
upload? I certainly didn't.
There is alot more then then just 1.2.0 ... check out the FTP site ...
As for taking advantage of that ... upload files to the
On Thu, 13 Jul 2006, Bruce Momjian wrote:
Marc G. Fournier wrote:
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 o
Marc G. Fournier wrote:
How would I go about taking advantage of that? And who did the 1.2.0
upload? I certainly didn't.
There is alot more then then just 1.2.0 ... check out the FTP site ...
As for taking advantage of that ... upload files to the file section
in *either* gborg or pgfoundry,
On Thu, 13 Jul 2006, Kris Jurka wrote:
On Thu, 13 Jul 2006, D'Arcy J.M. Cain wrote:
Wouldn't that be the job of the platform providers? Certainly I would
expect NetBSD to make it available as a package, both source and
binary, on every platform they support as they do for the thousands of
o
Jonah H. Harris wrote:
> 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.
Those fami
On Thu, 13 Jul 2006, Bort, Paul wrote:
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.)
Andrew posted about his desires for the future of the Buildf
On Fri, 14 Jul 2006, Thomas Hallgren wrote:
Marc G. Fournier wrote:
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 /b
On Thu, 13 Jul 2006, D'Arcy J.M. Cain wrote:
Wouldn't that be the job of the platform providers? Certainly I would
expect NetBSD to make it available as a package, both source and
binary, on every platform they support as they do for the thousands of
other packages they deal with.
Well Net
Marc G. Fournier wrote:
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 206
Jonah H. Harris wrote:
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
Joshua D. Drake wrote:
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
On Thu, 13 Jul 2006 16:15:04 -0500 (EST)
Kris Jurka <[EMAIL PROTECTED]> wrote:
> The fact that the JDBC driver requires no compilation for anyone on any
> platform is one reason for that. Anyone can visit the website and be
> working within minutes with no understanding of the build environment
On Thu, 13 Jul 2006, Tom Lane wrote:
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
Marc G. Fournier wrote:
> 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
> >
kleptog@svana.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
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'
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 ...
That is a great idea :)
Joshua D.
Jonah H. Harris wrote:
On 7/13/06, Marc G. Fournier <[EMAIL PROTECTED]> 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
fa
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-
On 7/13/06, Tom Lane <[EMAIL PROTECTED]> 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 sho
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"-li
On 7/13/06, Marc G. Fournier <[EMAIL PROTECTED]> 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
dist
-Original Message-
From: "Marc G. Fournier" <[EMAIL PROTECTED]>
To: "Rod Taylor" <[EMAIL PROTECTED]>
Cc: "Jonah H. Harris" <[EMAIL PROTECTED]>; "postgres hackers"
Sent: 13/07/06 20:06
Subject: Re: [HACKERS] Three weeks left unti
"Jonah H. Harris" <[EMAIL PROTECTED]> writes:
> On 7/13/06, Marc G. Fournier <[EMAIL PROTECTED]> 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 f
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 twi
On 7/13/06, Marc G. Fournier <[EMAIL PROTECTED]> 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 t
On 7/13/06, Marc G. Fournier <[EMAIL PROTECTED]> 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
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 h
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
On Thu, 13 Jul 2006, Jonah H. Harris wrote:
On 7/13/06, Dave Cramer <[EMAIL PROTECTED]> 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..
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 c
On 7/13/06, Marc G. Fournier <[EMAIL PROTECTED]> 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-c
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 l
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 .
[EMAIL PROTECTED] 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
essent
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.
[EMAIL PROTECTED] 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 wo
On 7/13/06, Tom Lane <[EMAIL PROTECTED]> 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
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 cur
[EMAIL PROTECTED] 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
Bruce,
On 7/7/06 10:13 AM, "Bruce Momjian" <[EMAIL PROTECTED]> 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
* Joshua D. Drake ([EMAIL PROTECTED]) 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 is
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 u
Andrew Dunstan wrote:
Tom Lane wrote:
Dave Cramer <[EMAIL PROTECTED]> 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 distribu
Nagayasu" <[EMAIL PROTECTED]>;
"Tom Lane" <[EMAIL PROTECTED]>; "pgsql-hackers@postgresql.org"
Sent: 13/07/06 14:43
Subject: Re: [HACKERS] Three weeks left until feature freeze
> As for the JVM worries, it's perfectly fine for anyone to ship the
>
> From: [EMAIL PROTECTED]
> [mailto:[EMAIL PROTECTED] 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 fa
"Jonah H. Harris" <[EMAIL PROTECTED]> 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 monolithi
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, f
-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 th
Tom Lane wrote:
Dave Cramer <[EMAIL PROTECTED]> 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
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 be
Bruce Momjian <[EMAIL PROTECTED]> 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 fro
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
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
dependenc
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, b
On 13-Jul-06, at 1:02 PM, Tom Lane wrote:
Bruce Momjian <[EMAIL PROTECTED]> 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 ...
Basica
[EMAIL PROTECTED] 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 Ja
On 7/13/06, Tom Lane <[EMAIL PROTECTED]> 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
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
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
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
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 i
Tom Lane wrote:
> Dave Cramer <[EMAIL PROTECTED]> 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 unif
On 13-Jul-06, at 9:29 AM, Jonah H. Harris wrote:
On 7/12/06, Tom Lane <[EMAIL PROTECTED]> 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
On 7/13/06, Dave Cramer <[EMAIL PROTECTED]> 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
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 eit
On 7/13/06, Dave Cramer <[EMAIL PROTECTED]> 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
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 pgfo
Dave Cramer <[EMAIL PROTECTED]> 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
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
On 13-Jul-06, at 9:22 AM, Jonah H. Harris wrote:
On 7/13/06, Josh Berkus 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
Postgres
On 7/12/06, Tom Lane <[EMAIL PROTECTED]> 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.
P
* Joshua D. Drake ([EMAIL PROTECTED]) 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 lice
On 7/13/06, Josh Berkus 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 prob
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 buil
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 g
1 - 100 of 159 matches
Mail list logo
