On Sep 1, 2006, at 9:32 , Tom Lane wrote:
Michael Glaesemann <[EMAIL PROTECTED]> writes:
On Sep 1, 2006, at 9:12 , Tom Lane wrote:
I agree that this seems like an oversight in the original
months/days/seconds patch, rather than behavior we want to keep.
But is DecodeInterval the only place wi
Hello
I am sending corrected version.
regards
Pavel Stehule
While this patch has new regression tests, it doesn't have new expected
output for it. Please update the patch to supply that. Thanks.
---
Pavel Stehule wr
On Sep 3, 2006, at 12:34 , Bruce Momjian wrote:
OK, I worked with Michael and I think this is the best we are going to
do to fix this. It has one TSROUND call for Powerpc, and that is
documented. Applied.
As I was working up regression tests, I found a case that this patch
doesn't handle.
Tom Lane wrote:
> Bruce Momjian <[EMAIL PROTECTED]> writes:
> > Tom Lane wrote:
> >> There is *no* credible use case for this (hint: MOVE FORWARD/BACKWARD
> >> ALL does not need this to work for >2G tables).
>
> > Already done because of bad coding. You want the TODO item removed too?
>
> As I s
Is this non-datetime integer only or both? I cannot reproduce the
failure here.
---
Michael Glaesemann wrote:
>
> On Sep 3, 2006, at 12:34 , Bruce Momjian wrote:
>
> > OK, I worked with Michael and I think this is the bes
Bruce Momjian <[EMAIL PROTECTED]> writes:
> Is this non-datetime integer only or both? I cannot reproduce the
> failure here.
On HPPA with float datetimes with today's code, Michael's case works
but it took me less than two minutes to find one that doesn't:
regression=# select interval '14 mon'
Michael Glaesemann wrote:
>
> On Sep 3, 2006, at 12:34 , Bruce Momjian wrote:
>
> > OK, I worked with Michael and I think this is the best we are going to
> > do to fix this. It has one TSROUND call for Powerpc, and that is
> > documented. Applied.
>
> As I was working up regression tests, I f
Bruce Momjian <[EMAIL PROTECTED]> writes:
> Is this something people are interested in? I am thinking no based on
> the lack of requests and the size of the patch.
Lack of requests? I was actually surprised by how enthusiastically people
reacted to it.
However I don't think the patch as is is r
On Sep 4, 2006, at 4:45 , Bruce Momjian wrote:
Another question. Is this result correct?
test=> select '999 months 999 days'::interval / 100;
?column?
-
9 mons 38 days 40:33:36
(1 row)
Should that be:
9 mons 3
Bruce Momjian <[EMAIL PROTECTED]> writes:
> Patch applied. Thanks.
For some reason I expected this patch to correct the portability errors
and design problems identified here:
http://archives.postgresql.org/pgsql-patches/2006-07/msg00100.php
Not only has it not fixed anything, it's made things w
Thanks Bruce,
Here are updated Japanese README, and uninstall_pgstattuple.sql.
Bruce Momjian wrote:
> Patch applied. Thanks.
>
> I updated the README documentation for the new functions, attached. I
> could not update the Japanese version of the README.
>
> ---
Tom Lane wrote:
> gcc -O2 -Wall -Wmissing-prototypes -Wpointer-arith -Winline
> -Wdeclaration-after-statement -Wendif-labels -fno-strict-aliasing -g -fpic
> -I. -I../../src/include -D_GNU_SOURCE -c -o pgstatindex.o pgstatindex.c
> pgstatindex.c: In function 'bt_page_items':
> pgstatindex.c:564
On Sep 3, 2006, at 20:00 , Michael Glaesemann wrote:
On Sep 1, 2006, at 9:32 , Tom Lane wrote:
Michael Glaesemann <[EMAIL PROTECTED]> writes:
On Sep 1, 2006, at 9:12 , Tom Lane wrote:
I agree that this seems like an oversight in the original
months/days/seconds patch, rather than behavior
Michael Glaesemann <[EMAIL PROTECTED]> writes:
> I realized there might be something in ecpg, and there was. I've
> updated the ecpg DecodeInterval to match. However, I haven't been
> able to get ecpg make check to work, so that part's untested.
This patch fails to apply --- looks like whitesp
On Sep 4, 2006, at 9:41 , Tom Lane wrote:
This patch fails to apply --- looks like whitespace got mangled in
transit. Please resend as an attachment.
Please let me know if you have any problems with this one.
Michael Glaesemann
grzm seespotcode net
10interval_input_0904T0855+0900.diff
De
Michael Glaesemann wrote:
>
> On Sep 4, 2006, at 4:45 , Bruce Momjian wrote:
>
> > Another question. Is this result correct?
> >
> > test=> select '999 months 999 days'::interval / 100;
> > ?column?
> > -
> > 9 mons 38 days 40:33:36
> > (1 row
Tom Lane wrote:
> Bruce Momjian <[EMAIL PROTECTED]> writes:
> > Is this non-datetime integer only or both? I cannot reproduce the
> > failure here.
>
> On HPPA with float datetimes with today's code, Michael's case works
> but it took me less than two minutes to find one that doesn't:
>
> regres
Michael Glaesemann <[EMAIL PROTECTED]> writes:
> On Sep 4, 2006, at 9:41 , Tom Lane wrote:
>> This patch fails to apply --- looks like whitespace got mangled in
>> transit. Please resend as an attachment.
> Please let me know if you have any problems with this one.
Ah, that one works --- applied
Bruce Momjian <[EMAIL PROTECTED]> wrote:
> Patch applied. Thanks.
The two attached patches fix contrib/pgstattuple.
pgstattuple.c.diff removes the fragmemtation reporting in pgstattuple().
It is no longer needed, because pgstatindex() has upward functionality now.
Also, the report using elog wa
Tom Lane wrote:
You mentioned being unable to get the ecpg tests to run on your
machine. I'm sure Michael and Joachim would like the details. The
ecpg regression tests are pretty new and some portability problems
are to be expected, but they seem to be passing on all the machines
Michael and
ITAGAKI Takahiro <[EMAIL PROTECTED]> writes:
> The two attached patches fix contrib/pgstattuple.
Good, applied. I made some additional changes to get install/uninstall/
reinstall to work cleanly after the latest additions, and to get it to
compile without warnings on a 64-bit Fedora machine. (It
Satoshi Nagayasu <[EMAIL PROTECTED]> writes:
> Tom Lane wrote:
>> pgstatindex.c: In function 'bt_page_items':
>> pgstatindex.c:564: warning: format '%d' expects type 'int', but argument 4
>> has type 'long unsigned int'
> I guess my '%d' should be '%zd', right?
No, that sounds even less portable
and here is the forgotten patch
Andrew Dunstan wrote:
Tom Lane wrote:
Andrew Dunstan <[EMAIL PROTECTED]> writes:
Peter Eisentraut wrote:
Ideally, we would get Python to tell us the right location, because
"use lib64 if it exists" isn't the right solution.
Is this fixed somewhere p
Tom Lane wrote:
> Michael Glaesemann <[EMAIL PROTECTED]> writes:
> > On Sep 4, 2006, at 9:41 , Tom Lane wrote:
> >> This patch fails to apply --- looks like whitespace got mangled in
> >> transit. Please resend as an attachment.
>
> > Please let me know if you have any problems with this one.
>
Applied.
---
Satoshi Nagayasu wrote:
> Thanks Bruce,
>
> Here are updated Japanese README, and uninstall_pgstattuple.sql.
>
> Bruce Momjian wrote:
> > Patch applied. Thanks.
> >
> > I updated the README documentation for
Bruce Momjian wrote:
> Michael Glaesemann wrote:
> >
> > On Sep 3, 2006, at 12:34 , Bruce Momjian wrote:
> >
> > > OK, I worked with Michael and I think this is the best we are going to
> > > do to fix this. It has one TSROUND call for Powerpc, and that is
> > > documented. Applied.
> >
> > As
Someone (David Fetter?) mentioned long ago that contrib/userlock could
not be moved into core because it is GPLed, and the author couldn't be
contacted to ask about re-licensing.
Andrew(@supernews) wrote a specification for the userlock functionality,
and I implemented the attached code based on h
27 matches
Mail list logo
