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
Is there any interest in a basic perl script that would read through a
postgresql.conf file and calculate approximate memory (and shared
memory) usage? Also, are there any other (simple for now) things I
should look at in the process? Asking because I'm getting annoyed with
doing this by hand
On Wed, Jul 12, 2006 at 06:47:56PM -0700, Marc Munro wrote:
On a related note, I can see no way to release Veil's shared memory
segment when postgres is shut down. Perhaps I should be thinking about
making the management of such shared memory segments something that
postgres does on behalf
- add a new boolean to pg_operator to allow us to define which
operators offer true equality ...
This would be useful for other purposes too, as we keep coming up
against what's the equality operator for this datatype problems.
However, the restriction to true equality, such that
On Wed, 2006-07-12 at 22:34 -0400, Tom Lane wrote:
More generally, I don't believe in hacks that only work for a small
number of built-in types: to me, that's prima facie evidence that you
haven't thought the problem through.
I agree an attempt at a simple definition of the required
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
Tatsuo Ishii [EMAIL PROTECTED] writes:
Interesting. We (some Japanese companies including SRA OSS,
Inc. Japan) did some PG scalability testing using a Unisys's big 16
(physical) CPU machine and found PG scales up to 8 CPUs. However
beyond 8 CPU PG does not scale anymore. The result
There is a problem of implication here, AFAICS:
When a user SQL asks
WHERE col1 = 7
which equality level is meant when several exist?
Well, the operator must be unique, so there is no problem.
Unique in the sense that an operator with the same name ('=' in this
case)
and argument
Andrew,
Josh did something like this and I wrote some java to do some of it.
It's in a project called pgconfigurator (I think)
dave
On 12-Jul-06, at 2:46 PM, Andrew Hammond wrote:
Is there any interest in a basic perl script that would read through a
postgresql.conf file and calculate
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
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
Tatsuo Ishii [EMAIL PROTECTED] writes:
18% in s_lock is definitely bad :-(. Were you able to determine which
LWLock(s) are accounting for the contention?
Yes. We were interested in that too. Some people did addtional tests
to determin that. I don't have the report handy now. I will report
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
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,
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 01:13 -0300, Tom Lane wrote:
Marc Munro [EMAIL PROTECTED] writes:
... A better solution from my point of view would be
to simply move the call to process_preload_libraries to a point
after
shared memory has been set up. Is there some reason this could not
be
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 Mittwoch, Juli 12, 2006 20:58:08 -0500 Jaime Casanova
[EMAIL PROTECTED] wrote:
if nobody step up i can do the list.
i think this is the last patch that he post:
http://archives.postgresql.org/pgsql-hackers/2006-03/msg00586.php
The code drifted since then in some parts. I'll sent a
I just recently came to know that geocities.com is down. It is
accessible from geocities.yahoo.com though, but my site is still not
accessible. I had deleted my local copy, relying on the gecities, and
almost lost it; but then I twisted some knobs in geocities.yahoo.com
to get the file back...
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 Mittwoch, Juli 12, 2006 09:30:38 -0700 Joe Conway [EMAIL PROTECTED]
wrote:
Jaime Casanova wrote:
is anybody working on the Bernd Helmle's updateable views patch? or
know what the status of this is?
I'm still working on this and trying to get all open issues done for 8.2
feature
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
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
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
Just confirming that its fixed ...
Marc G. Fournier Hub.Org Networking Services (http://www.hub.org)
Email . [EMAIL PROTECTED] MSN . [EMAIL PROTECTED]
Yahoo . yscrappy Skype: hub.orgICQ . 7615664
---(end
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
-Original Message-
From: Jonah H. Harris [EMAIL PROTECTED]
To: Josh Berkus josh@agliodbs.com
Cc: Thomas Hallgren [EMAIL PROTECTED]; Dave Cramer [EMAIL PROTECTED];
David Fetter [EMAIL PROTECTED]; Satoshi Nagayasu [EMAIL PROTECTED];
Tom Lane [EMAIL PROTECTED];
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
Hi All,
I've been working on a small module that I will be pluging into my
local PostreSQL 8.x database and am in need of doing some table locking.
At this time, I've used various other examples to no avail and was
wondering what the proper method for aquiring a table lock within the
module
On 7/13/06, Bernd Helmle [EMAIL PROTECTED] wrote:
I'm still working on this and trying to get all open issues done for 8.2
feature freeze.
Sweet!
--
Jonah H. Harris, Software Architect | phone: 732.331.1300
EnterpriseDB Corporation| fax: 732.331.1301
33 Wood Ave S, 2nd Floor
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
I intended to post this anyway as a followup to the conference session,
but I have been spurred to do it nowby the Pl/J(ava) discussion.
I outlined a number of possible directions for buildfarm, and we had a
good discussion.
Based on that, my current intention is to make provision for the
[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
Chris Bowlby [EMAIL PROTECTED] writes:
I've been working on a small module that I will be pluging into my
local PostreSQL 8.x database and am in need of doing some table locking.
At this time, I've used various other examples to no avail and was
wondering what the proper method for
On Thu, Jul 13, 2006 at 03:01:31PM -0300, Chris Bowlby wrote:
Hi All,
I've been working on a small module that I will be pluging into my
local PostreSQL 8.x database and am in need of doing some table locking.
At this time, I've used various other examples to no avail and was
wondering
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
I am seeing buildfarm failures on AIX because stdio.h is being included
before pg_config.h (which has the definition of _LARGE_FILES).
The problem is stemming from math.h including stdlib.h, which (after
several more inclusions) ends up including stdio.h.
This is where the fgetpos64 different
What is the state of the following items that have been previously
discussed?
. MERGE (at least in PK case)
. multiple values clauses for INSERT
. recursive WITH queries
Thanks
andrew
---(end of broadcast)---
TIP 1: if posting/reading
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
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
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 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
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
Andrew Dunstan [EMAIL PROTECTED] writes:
What is the state of the following items that have been previously
discussed?
. MERGE (at least in PK case)
No submitted patch; no one working on it AFAIK; doesn't look like
something that could get done in the next three weeks.
. multiple values
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
Marc G. Fournier wrote:
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
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.
Rocco Altier [EMAIL PROTECTED] writes:
If I move math.h down after postgres.h in nodeHash.c, the problem
goes away.
Bruce, you broke it. Have you forgotten the fundamental inclusion rule?
postgres.h (or postgres_fe.h, or c.h) first, then system headers, then
our own other headers.
Marc G. Fournier wrote:
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
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
On 7/13/06, Tom Lane [EMAIL PROTECTED] wrote:
. recursive WITH queries
I believe Jonah has given up on fixing the originally-submitted
patch, but he mentioned at the code sprint that non-recursive
WITH is potentially doable in time for 8.2. Not sure if that's
a sufficiently important case to
Mario Weilguni wrote:
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.
No, it will not because RESET CONNECTION can mess up interface code that
doesn't want the
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
Fixed.
---
Tom Lane wrote:
Rocco Altier [EMAIL PROTECTED] writes:
If I move math.h down after postgres.h in nodeHash.c, the problem
goes away.
Bruce, you broke it. Have you forgotten the fundamental inclusion rule?
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
Now it dies on nodeSubplan.c...
I am guessing there will be others as well.
Perhaps a check to make sure postgres.h is first in the includes can be
added to the include checking scripts you have been updating?
Thanks,
-rocco
-Original Message-
From: Bruce Momjian
On Thu, 13 Jul 2006, Lukas Smith wrote:
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
Marc G. Fournier wrote:
But, that isn't our role ... that should be the role of whomever takes
on the role of 'maintainer' for such a monolithic distribution ... its
no more our role to decide that pl/Java is better or worse then pl/J ...
our role is to provide that core for everyone else to
Rocco Altier wrote:
Now it dies on nodeSubplan.c...
I am guessing there will be others as well.
I check them all the math.h mentions.
---
Perhaps a check to make sure postgres.h is first in the includes can be
1 - 100 of 165 matches
Mail list logo
