On Thu, 2005-11-03 at 10:32 -0500, Tom Lane wrote:
I'd feel a lot happier about this if we could keep the dynamic range
up to, say, 10^512 so that it's still true that NUMERIC can be a
universal parse-time representation. That would also make it even
more unlikely that anyone would complain
On Fri, 2005-11-04 at 13:21 -0500, Bruce Momjian wrote:
David Fetter wrote:
On Fri, Nov 04, 2005 at 01:01:20PM -0500, Tom Lane wrote:
I'm inclined to treat this as an outright bug, not just a minor
performance issue, because it implies that a sufficiently long psql
script would
Morning,
pgInstaller 8.1 has been built and uploaded to
ftp.postgresql.org/pub/win32. Please take a look if you can and report
any glaring errors.
Hiroshi; I think we're ready for the Japanese version whenever you're
ready :-)
Regards, Dave.
---(end of
Simon Riggs [EMAIL PROTECTED] writes:
On Thu, 2005-11-03 at 10:32 -0500, Tom Lane wrote:
I think we could make it go by cramming the sign and
the high-order dscale bit into the first NumericDigit --- the
digit itself can only be 0.. so there are a couple of bits
to spare.
I've got a
Gavin Sherry [EMAIL PROTECTED] writes:
I had a colleague test for me on his IRIX (6.5?) MIPSPRO machine. The
following regression tests fail:
http://treehou.se/~finn/regression.diffs
Hm, looks like strtod() has some bizarre behavior for input infinity
on that machine (NOT just failing to
Simon Riggs wrote:
On Fri, 2005-11-04 at 13:21 -0500, Bruce Momjian wrote:
David Fetter wrote:
On Fri, Nov 04, 2005 at 01:01:20PM -0500, Tom Lane wrote:
I'm inclined to treat this as an outright bug, not just a minor
performance issue, because it implies that a sufficiently
Morning,
pgInstaller 8.1 has been built and uploaded to
ftp.postgresql.org/pub/win32. Please take a look if you can and report
any glaring errors.
Hiroshi; I think we're ready for the Japanese version whenever you're
ready :-)
Thanks! However, I have still left much work.
I needed of
-Original Message-
From: Hiroshi Saito [mailto:[EMAIL PROTECTED]
Sent: Sun 11/6/2005 6:11 PM
To: Dave Page
Cc: pgsql-hackers@postgresql.org
Subject: Re: [HACKERS] pgInstaller 8.1 built
Hiroshi; I think we're ready for the Japanese version whenever you're
ready :-)
Thanks!
yes, MAJOR goof on my part. My brain cells were not firing quite right :(
For those really interested, here are some resources:
http://www.cs.wisc.edu/~cs354-1/cs354/karen.notes/reps.flpt.html
http://cch.loria.fr/documentation/IEEE754/ACM/goldberg.pdf
On Fri, 4 Nov 2005, Tom Lane wrote:
The 8.1 supported-platforms list is looking pretty good, I think -- we
don't have updates for every single combination of OS and hardware,
but we have updates for every OS and at least one instance of all
supported CPU types.
Except IRIX. There's been no
On Mon, 7 Nov 2005, Hiroshi Saito wrote:
Morning,
pgInstaller 8.1 has been built and uploaded to
ftp.postgresql.org/pub/win32. Please take a look if you can and report
any glaring errors.
Hiroshi; I think we're ready for the Japanese version whenever you're
ready :-)
Thanks! However, I have
I'm noticing that the latest pgindent run has frequently rejustified
block comments to end in column 80 or 81, causing them to wrap in an
ugly way (at least in emacs). I thought the agreement was to limit
lines to 79 chars max?
For one example see lines 475 ff in
Hey all,
I was doing a test run of a live dump from 8.0.2 to 8.1.0, and 8.1.0 took a
segmentation violation 1 hour into the operation. My plan is to re-do the
dump/restore, and if it fails again, to re-compile with debug and cassert, and
try to get a core.
The command line was (8.1.0 is on
Which version is first in your path, 8.0 or 8.1? If 8.0, do you get a
different result from the 8.1 binaries?
cheers
andrew
Robert Creager wrote:
Hey all,
I was doing a test run of a live dump from 8.0.2 to 8.1.0, and 8.1.0 took a
segmentation violation 1 hour into the operation. My
Hello
I execute select anyrowfce(..) in plpgsql via exec_run_select
I need to get inner row, but I can't find good way for it
retval = SPI_getbinval(estate-eval_tuptable-vals[0],
estate-eval_tuptable-tupdesc,1);
rettype = SPI_gettypeid(estate-eval_tuptable-tupdesc,1);
rettupdesc =
Marc,
Okay, I found an OpenSSL-0.9.7 and readline library. The IRIX 6.5 IP35
also passed with the OpenSSL and readline included. This is with the
IRIX cc and not gcc.
Ken
On Mon, Oct 24, 2005 at 11:51:26AM -0300, Marc G. Fournier wrote:
We have released a Release Candidate 1 of the
Marc,
I just finished a build with the 8.1beta4 for IRIX 6.5 but without
the nuances. We do not really use SGI other than in special circumstances
but the regression test passed all tests:
configure --without-readline
using IRIX cc.
Ken
On Mon, Oct 24, 2005 at 11:51:26AM -0300, Marc G.
From: Marc G. Fournier
Hiroshi; I think we're ready for the Japanese version whenever you're
ready :-)
Thanks! However, I have still left much work.
I needed of several days. then, do my best.
several days isn't a biggie ... that's one of the reasons why we left
such a gap between
Pavel Stehule [EMAIL PROTECTED] writes:
rettupdesc = lookup_rowtype_tupdesc(rettype,0);
This is wrong --- if you don't know what typmod to use, *always* pass -1
not 0. (I suspect that rettype is RECORD and that -1 would have
resulted in a NULL result.)
It seems like SPI is missing a needed
When grilled further on (Sun, 06 Nov 2005 18:52:40 -0500),
Andrew Dunstan [EMAIL PROTECTED] confessed:
Which version is first in your path, 8.0 or 8.1? If 8.0, do you get a
different result from the 8.1 binaries?
8.0 was first. I've specified the correct full path now for the
On Sun, 6 Nov 2005, Tom Lane wrote:
Gavin Sherry [EMAIL PROTECTED] writes:
I had a colleague test for me on his IRIX (6.5?) MIPSPRO machine. The
following regression tests fail:
http://treehou.se/~finn/regression.diffs
Hm, looks like strtod() has some bizarre behavior for input infinity
21 matches
Mail list logo
