Tom Lane wrote:
> It's too bad that gcc doesn't have a
> -Wno-snarkiness-about-system-headers-thank-you switch.
It does have a switch to *add* snarkiness about system headers, but does
not do it by default.
The problem in this case is that an uncast null pointer constant is not
always a suffici
Tom Lane <[EMAIL PROTECTED]> wrote:
> Bruce Momjian <[EMAIL PROTECTED]> writes:
> >> -is compared to the total number of tuples inserted, updated, or
> >> deleted
> >> +is compared to the total number of tuples inserted or updated
>
> As best I can tell, this description is even further
Tom Lane wrote:
> Bruce Momjian <[EMAIL PROTECTED]> writes:
> >> -is compared to the total number of tuples inserted, updated, or
> >> deleted
> >> +is compared to the total number of tuples inserted or updated
>
> As best I can tell, this description is even further away from the
> actua
Bruce Momjian <[EMAIL PROTECTED]> wrote:
> Patch applied. Thanks. Your documentation changes can be viewed in
> five minutes using links on the developer's page,
> http://www.postgresql.org/developer/testing.
Thanks. Don't we need to backport it to 8.1 and 8.2?
It was changed at the integratio
Bruce Momjian <[EMAIL PROTECTED]> writes:
>> -is compared to the total number of tuples inserted, updated, or deleted
>> +is compared to the total number of tuples inserted or updated
As best I can tell, this description is even further away from the
actual CVS HEAD behavior than the previ
Bruce Momjian <[EMAIL PROTECTED]> writes:
> Alvaro Herrera wrote:
>> pg_regress.c: In function `spawn_process':
>> pg_regress.c:914: warning: missing sentinel in function call
> You can apply this, but it sure seems like a compiler/include file bug
> to me, even with the 64-bit explaination.
Ther
Patch applied. Thanks. Your documentation changes can be viewed in
five minutes using links on the developer's page,
http://www.postgresql.org/developer/testing.
---
ITAGAKI Takahiro wrote:
> I reported an incorrect desc
This has been saved for the 8.4 release:
http://momjian.postgresql.org/cgi-bin/pgpatches_hold
---
Gavin M. Roy wrote:
> This is the patch I proposed on hackers to make pg_dump optionally ignore
> tablespaces. The p
Alvaro Herrera wrote:
> Stefan Kaltenbrunner just let me know via Jabber that there's a warning
> in pg_regress.c:
>
> pg_regress.c: In function `spawn_process':
> pg_regress.c:914: warning: missing sentinel in function call
>
> This small patch would seem to fix it, according to
> http://www.li
I have applied the attached patch that documents the age() behavior,
plus fixes the mismatch sign for seconds by using part of Tom's earlier
patch.
I agree we want to keep the symmetry we have. We can call this item
closed.
-
I am fighting some fires in my day job.
My pesonal TODO list for pg up to beta is:
. fix chunking muddle (see recent emails)
. complete CSV logs patch
. harden MSVC builds
I'll get to this when I can. I can dig up the patch I did if you want
it again.
cheers
andrew
Magnus Hagander wrote
Your patch has been added to the PostgreSQL unapplied patches list at:
http://momjian.postgresql.org/cgi-bin/pgpatches
It will be applied as soon as one of the PostgreSQL committers reviews
and approves it.
---
Al
Your patch has been added to the PostgreSQL unapplied patches list at:
http://momjian.postgresql.org/cgi-bin/pgpatches
It will be applied as soon as one of the PostgreSQL committers reviews
and approves it.
---
Si
"Tom Lane" <[EMAIL PROTECTED]> writes:
> No, my proposed patch doesn't change that. It might be that we should
> provide an "integer division" operator for NUMERIC, so that you can get
> at the exact result of trunc(x/y).
I was also thinking that if the denominator had only factors of 2 and 5 we
On Tue, 2007-07-17 at 01:28 -0400, Bruce Momjian wrote:
> Your patch has been added to the PostgreSQL unapplied patches list at:
>
> http://momjian.postgresql.org/cgi-bin/pgpatches
>
> It will be applied as soon as one of the PostgreSQL committers reviews
> and approves it.
>
> ---
Gregory Stark <[EMAIL PROTECTED]> writes:
> "Tom Lane" <[EMAIL PROTECTED]> writes:
>> Well, this doesn't take a lot of numerical methods background: the
>> fundamental problem is that the existing code generates an *approximate*
>> answer, whereas people who are doing div and mod on large integers
I used to have a different patch from Andrew that did part of this, and
more, and conflicted rather badly with it. However, I never got around
to applying that one, and I can't seem to find it anymore.
Andrew -do you recall if you had all this in yours, and is it still
something you want in, or sh
"Affan Salman" <[EMAIL PROTECTED]> writes:
> Thanks, Tom. We're also back-patching this, right?
Yeah, working on that now.
regards, tom lane
---(end of broadcast)---
TIP 2: Don't 'kill -9' the postmaster
"Tom Lane" <[EMAIL PROTECTED]> writes:
> Gregory Stark <[EMAIL PROTECTED]> writes:
>> "Tom Lane" <[EMAIL PROTECTED]> writes:
>>> Yeah. I was basically waiting to see if anyone could come up with a
>>> faster solution. Since no one seems to have an idea how to do it
>>> better, I'm inclined to ap
>
> OK, that's what I get for opining before checking the code ;-).
Your *cerebral call graph visits* have a knack of being spot on, way
more than often. :-)
>
> Will apply.
Thanks, Tom. We're also back-patching this, right?
--
Affan Salman
EnterpriseDB Corporation http
Gregory Stark <[EMAIL PROTECTED]> writes:
> "Tom Lane" <[EMAIL PROTECTED]> writes:
>> Yeah. I was basically waiting to see if anyone could come up with a
>> faster solution. Since no one seems to have an idea how to do it
>> better, I'm inclined to apply the patch for 8.3.
> My only reservation
"Tom Lane" <[EMAIL PROTECTED]> writes:
> Michael Paesold <[EMAIL PROTECTED]> writes:
>> Please, let's revisit this, and not postpone it without further
>> discussion. I never knew about the correctness issues in div_var(), but
>> since I know about it, I feel I am just waiting until that problem
Stephan Szabo <[EMAIL PROTECTED]> writes:
> On Sun, 15 Jul 2007, Tom Lane wrote:
>> I don't think this is right. If the original tuple was inserted by a
>> subtransaction of our transaction, it will have been checked at
>> subtransaction subcommit, no?
> I don't think the subtransaction subcommit
Michael Paesold <[EMAIL PROTECTED]> writes:
> Please, let's revisit this, and not postpone it without further
> discussion. I never knew about the correctness issues in div_var(), but
> since I know about it, I feel I am just waiting until that problem will
> hit me or anyone else.
Yeah. I was
Please, let's revisit this, and not postpone it without further
discussion. I never knew about the correctness issues in div_var(), but
since I know about it, I feel I am just waiting until that problem will
hit me or anyone else.
So can you, Tom, please describe in what situations the old code
25 matches
Mail list logo
