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
syntax
Ü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 meet
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
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 that
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
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
On 7/13/06, Josh Berkus josh@agliodbs.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
* 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
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.
PL/J
On 13-Jul-06, at 9:22 AM, Jonah H. Harris wrote:
On 7/13/06, Josh Berkus josh@agliodbs.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
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
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 way
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
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 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
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 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
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
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
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, 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
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 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
[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
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 ...
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,
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
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
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 from
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
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
-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
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,
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 monolithic core
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 farm
@postgresql.org
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
JVM. If we wanted to include the JVM in official PostgreSQL
distributions, we can do so. Otherwise, we can just
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
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
* 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 isn't
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 be
[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
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 at
[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 would
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
[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
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
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
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
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
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...
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
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
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 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
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
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 for people;
-Original Message-
From: Marc G. Fournier [EMAIL PROTECTED]
To: Rod Taylor [EMAIL PROTECTED]
Cc: Jonah H. Harris [EMAIL PROTECTED]; postgres hackers
pgsql-hackers@postgresql.org
Sent: 13/07/06 20:06
Subject: Re: [HACKERS] Three weeks left until feature freeze
The gborg vs pgfoundry
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
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
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 should
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
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
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.
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
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 to
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
pretty
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
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 or
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
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
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
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
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
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
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
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
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, 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
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
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, but
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 operating
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 you going
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,
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,
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 packagers
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
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
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
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
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,
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
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
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 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
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
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
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
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. (Contrast
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 not the
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
1 - 100 of 157 matches
Mail list logo
