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 behal
> > > - 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" eq
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 functio
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 A
> > 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 anymor
> 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 t
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 appro
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
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
* 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/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
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 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
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
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
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
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 eit
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 unif
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
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
>
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 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 Ja
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
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
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
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 fro
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
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 t
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 th
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
"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
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 o
> 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
-Original Message-
From: "Jonah H. Harris" <[EMAIL PROTECTED]>
To: "Josh Berkus"
Cc: "Thomas Hallgren" <[EMAIL PROTECTED]>; "Dave Cramer" <[EMAIL PROTECTED]>;
"David Fetter" <[EMAIL PROTECTED]>; "Satoshi Nagayasu" <[EMAIL PROTECTED]>;
"Tom Lane" <[EMAIL PROTECTED]>; "pgsql-hackers@post
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
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
* 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
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
[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 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
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
[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
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 w
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 RPMs.
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
essent
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 aq
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
> wonder
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
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 def
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 throug
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:
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 c
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 pgfoundry
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 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 jus
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 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
"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
-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 until feature freeze
> The gborg vs pgfoundry issue is being
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
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, 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
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 valu
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-
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
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 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 Bizgre
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'
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 t
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
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
> >
Fixed.
---
Tom Lane wrote:
> "Rocco Altier" <[EMAIL PROTECTED]> writes:
> > If I move down after "postgres.h" in nodeHash.c, the problem
> > goes away.
>
> Bruce, you broke it. Have you forgotten the fundamental inclusion
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 co
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 [mailto:[EM
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 cou
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 b
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
>
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
1 - 100 of 169 matches
Mail list logo
