At 11:35 7/08/00 -0400, Tom Lane wrote:
>
>Perhaps the old way of considering equality only to float accuracy
>is more useful, even though it opens us up to problems like overflow
>errors in "float4var = 1e100". Comments anyone?
>
The following frightened me a little:
pjw=# select float4(10.1);
At 12:11 7/08/00 -0400, Tom Lane wrote:
>Philip Warner <[EMAIL PROTECTED]> writes:
>> pjw=# select float8(float4(10.1));
>> float8
>> --
>> 10.103814697
>> (1 row)
>
>> I would have expected the latter to be at worst 10.10 +/-
>> .01.
>
>float4 is
Philip Warner <[EMAIL PROTECTED]> writes:
> pjw=# select float8(float4(10.1));
> float8
> --
> 10.103814697
> (1 row)
> I would have expected the latter to be at worst 10.10 +/-
> .01.
float4 is good to about 7 decimal digits (24 mantissa bits)
Philip Warner <[EMAIL PROTECTED]> writes:
> Now I understand, but it doesn't quite make sense given what was displayed.
> The float4 value is *displayed* as 10.1, not 10.101, so I had assumed
> that there was a level of either accuracy or display rouding happening.
In float4-to-ASCII, yes. M
I am trying to copy a table from my local database to a client's. The
problem is I keep getting a message from pg_dump:
"can't find template1 database. You are really hosed."
The docs say that this usually means the postmaster is not running but it
is. In fact, I can get into the database and
At 16:12 7/08/00 +, Thomas Lockhart wrote:
>> I would have expected the latter to be at worst 10.10 +/-
>> .01.
>> Am I missing something?
>
>10.1 can't be represented exactly, so the float8 representation has bits
>set way down at the low end of the mantissa. When conv
> I would have expected the latter to be at worst 10.10 +/-
> .01.
> Am I missing something?
Well, yes :)
10.1 can't be represented exactly, so the float8 representation has bits
set way down at the low end of the mantissa. When converting to float4
those low bits get rou
> Perhaps the old way of considering equality only to float accuracy
> is more useful, even though it opens us up to problems like overflow
> errors in "float4var = 1e100". Comments anyone?
I would not have anticipated this either. I agree that downconverting to
float4 is the right solution.
Po
"Romanenko Mikhail" <[EMAIL PROTECTED]> writes:
> testfloat=# update tftbl set f1=10.1 where f1=10 and f2=20;
> UPDATE 1
> testfloat=# update tftbl set f2=20.2 where f1=10.1 and f2=20;
> UPDATE 0
The second update is failing to find any tuple that satisfies f1 = 10.1,
because f1 is a float4 varia
"Morten W. Petersen" <[EMAIL PROTECTED]> writes:
> NOTICE: Rel inmail: Uninitialized page 433 - fixing
> I got this message trying to vacuum the DB. Can this be the problem?
No, that would be a symptom of recovery from an earlier problem.
One plausible explanation is that you're trying to inse
NOTICE: Rel inmail: Uninitialized page 433 - fixing
I got this message trying to vacuum the DB. Can this be the problem? If
so, does anyone know why this may be happening?
-Morten
Is there any way to compile libpq for Win32 for it to produce output in
UNICODE?
What I want is something like that:
wchar_t* utfbuffer;
...
utfbuffer = PQgetvalue(res, i, j);
wprintf("%s", utfbuffer);
...
and the program produces normal output, not the mess of Chinese/Thai/etc
symbols.
Alex B
> It'll help if you provide more info, like what version of PostgreSQL,
> what OS and version, example queries, etc..
Woop. The database that's working is a PostgreSQL 6.5 on Debian 2.1, the
database that isn't is a PostgreSQL 6.5 on Suse 6.4, both x86 architecture
machines.
The PostgreSQL on
The following message is a courtesy copy of an article
that has been posted to comp.lang.java.databases as well.
I have a Java database toolkit which I'm trying to make as portable as
possible. It has to work with databases with minimal features as well
as with databases with more features.
The
After trying to upgrade PostgreSQL from 6.5.3 to 7.0.2 I got into trouble with float4.
I'll try to explain it by example.
postgres@lee: ~$ createdb -E LATIN1 -e testfloat
CREATE DATABASE "testfloat" WITH ENCODING = 'LATIN1'
CREATE DATABASE
postgres@lee: ~$ psql testfloat
testfloat=# create table
On Mon, 7 Aug 2000, Morten W. Petersen wrote:
> Hiya guys
>
> I'm having a problem with a PostgreSQL backend, the problem being that the
> backend can die, from the simplest queries. I'm wondering if this can be
> the sympthom of a corrupted database, or just a buggy version of Postgre.
It'll
*** Stephan Szabo <[EMAIL PROTECTED]> [Sunday, 06.August.2000, 14:26
-0700]:
>
> Actually, you should only be seeing one constraint out on the referencing
> table and two out of the referenced one, but yes, fundamentally it only is
> dumping the constraint triggers for the table you are dumping
Hiya guys
I'm having a problem with a PostgreSQL backend, the problem being that the
backend can die, from the simplest queries. I'm wondering if this can be
the sympthom of a corrupted database, or just a buggy version of Postgre.
-Morten
18 matches
Mail list logo
