I have finally caught up on my email. The first week after returning
from vacation, I read the 3400 emails from May (~100/day), and the
second week dealt with emails requiring special attention. All
outstanding patches should now be applied.
I am now back to trying to polish up open issues for
Bruce Momjian wrote:
> Tom Lane wrote:
> > Neil Conway <[EMAIL PROTECTED]> writes:
> > > Hmmm... Well, I'll take a look at it, but I'll probably just leave it
> > > be -- since the optimization might actually return invalid results, it
> > > doesn't seem like a very valuable thing to have, IMHO.
>
Tom Lane wrote:
> Bruce Momjian <[EMAIL PROTECTED]> writes:
> > Is there any value to KQSO parameter? It was for complex OR clauses. I
> > thought Tom fixed most of that.
>
> The last set of tests that I did (~7.0) showed that it was still
> marginally faster than the default approach. Not a "
Matthew Tedder dijo:
> On Friday 14 June 2002 04:41 pm, Bill Cunningham wrote:
> > Matthew Tedder wrote:
> > >How feasible would it be to create this functionality in PostgreSQL:
> > >
> > >One creates a test version of a database that initially consists of
> > >read-links to the production
Comments at appropriate places below..
On Friday 14 June 2002 04:41 pm, Bill Cunningham wrote:
> Matthew Tedder wrote:
> >Question:
> >
> >How feasible would it be to create this functionality in PostgreSQL:
> >
> >One creates a test version of a database that initially consists of
> >read-l
If on one is has outstanding libpq++ patches, I will run libpq++ through
my new tools src/tools/pgindent/pgcppindent. It uses astyle. I can
also wait for 7.3 beta and run it then.
---
Neil Conway wrote:
> On Wed, 12 Jun 2
"Nigel J. Andrews" <[EMAIL PROTECTED]> writes:
> + if (estate->eval_processed != 0)
> + exec_set_found(estate, true);
To be actually useful the command would have to set FOUND to either
true or false depending on whether it computed a row or not. So the
correct pa
Bruce Momjian <[EMAIL PROTECTED]> writes:
> Has this been resolved and patched?
No, I think we were still debating how it should work when the
discussion died off...
regards, tom lane
---(end of broadcast)---
TIP 4: Don't '
On Fri, 14 Jun 2002, Alvaro Herrera wrote:
> Tom Lane dijo:
>
> > "Nigel J. Andrews" <[EMAIL PROTECTED]> writes:
> > > However, because PERFORM discards the results of a query it is only
> > > useful for side effects of the query.
>
> > Okay. I guess the next question is whether PERFORM *sho
> You wrote "was either to voluminous" instead of "was either too voluminous"
> in the first paragraph of the appendix...
Thanks!
- Thomas
---(end of broadcast)---
TIP 5: Have you checked our extensive FAQ?
http://www.postgre
Rocco Altier wrote:
>
> On Fri, 14 Jun 2002, Mike Mascari wrote:
>
> > That is what I want to do, except by extending the grammar. I must admit
> > to actually being surprised that a TEMP table created inside a
> > transaction lived after the transaction completed. That's when I looked
> > at th
You wrote "was either to voluminous" instead of "was either too voluminous"
in the first paragraph of the appendix...
Chris
- Original Message -
From: "Thomas Lockhart" <[EMAIL PROTECTED]>
To: "PostgreSQL Hackers List" <[EMAIL PROTECTED]>
Sent: Saturday, June 15, 2002 1:16 PM
Subject: [H
12 matches
Mail list logo
