d be trashed and
rewritten. My patch, again, was just a hack to make the existing code/design
work and at least does provide some functionality now.
Robert B. Easter
---(end of broadcast)---
TIP 6: Have you searched our list archives?
http://www.postgresql.org/search.mpl
there is no exponent, maybe only 52 bits are really
in the mantissa. If you try rounding numbers <= 4503599627370495 (2^52 - 1),
maybe you'll get expected results. The hidden bit is 0. Could be that round
or rint (whatever it is) always makes the hidden bit 1 when I think it shou
:INT8;
?column?
--
2
(1 row)
On Thursday 25 January 2001 22:52, Tom Lane wrote:
> "Robert B. Easter" <[EMAIL PROTECTED]> writes:
> > This problem is not specific to Postgres.
>
> The fact that 5*27.81*100 != 27.81*100*5 is certainly a garden-variety
> floating-
On Thursday 25 January 2001 22:52, Tom Lane wrote:
> "Robert B. Easter" <[EMAIL PROTECTED]> writes:
> > This problem is not specific to Postgres.
>
> The fact that 5*27.81*100 != 27.81*100*5 is certainly a garden-variety
> floating-point roundoff error
aybe a rounding problem.
On Thursday 25 January 2001 05:34, Max Vaschenko wrote:
> Postgres-7.0.3-2
> RedHat-6.2
>
> SELECT int8(5*27.81*100);
> 13904
>
> SELECT int4(5*27.81*100);
> 13905
>
> SELECT int8(27.81*100*5);
> 13905
--
Robert
On Saturday 06 January 2001 17:56, Tom Lane wrote:
> "Robert B. Easter" <[EMAIL PROTECTED]> writes:
> > The IS operator is supposed to return only TRUE or FALSE, never NULL.
> > See ISO/IEC 9075-2:1999 6.30
>
> Yeah, we do not implement IS TRUE, IS FALSE,
true is null;
?column?
--
f
(1 row)
pgcvs=# select null is true;
?column?
--
(1 row)
This is strange. Just reversing the order changes the result.
I'm using the cvs version. I think 7.0.3 has all this (wrong?) behavior too.
--
Robert B. Easter [EMAIL PRO
On Tuesday 19 December 2000 22:11, Jeff Davis wrote:
>
> create function bool_to_int(bool) returns int as 'select 1 as result
> where $1 union select 0 as result where not $1;' language 'sql';
This is an alternative way to make the bool_to_int, but it doesn't solve your
problem unless the union
SQL reference. I spent some time on this
today and updated a file of mine at
http://www.comptechnews.com/~reaster/dbdesign.html#three-valued-logic
to take into consideration these things. If you do take a look at it and
find an error, I will fix it. This dbdesign.html file is a file linked to
behave as follows: all boolean tests
involving NULL return FALSE except the explicit test IS NULL, e.g., if NULL
is a possibility, it has to be tested for explicity using IS NULL or IS NOT
NULL. (any additions/corrections to this definition/note will be happily
considered)
I think Bruce Momji
CT atestfun();
The ouput should be:
atestfun
----------
This is a \ test.
(1 row)
But instead, it returns:
atestfun
--
This is a test.
(1 row)
Is this a pg_dump bug or is there there some way to do this right?
--
Robert B. Easter [EMAIL PROTECTED] -
- CompTechNews Message Board http://www.comptechnews.com/ -
- CompTechServ Tech Services http://www.comptechserv.com/ -
-- http://www.comptechnews.com/~reaster/
POSTGRESQL BUG REPORT TEMPLATE
Your name : Robert B. Easter
Your email address : [EMAIL PROTECTED
This is a minor problem, but maybe easily fixed? ...
If you create a database and load in the following sql, dump it with pg_dump,
then try to restore it (psql -e db < dump), it will get a parser error loading
the function when it encounters the "\'" in the regsub functions. I've had many
troub
On Fri, 07 Jul 2000, Tom Lane wrote:
> Chris Bitmead <[EMAIL PROTECTED]> writes:
> UPDATE foo
> SET bar = (SELECT min(f1) FROM othertab
> WHERE othertab.keycol = foo.keycol)
> WHERE condition-determining-which-foo-rows-to-update
> if you wanted to use an aggregat
SELECT 3 !;
ERROR: parser error at or near ""
SELECT 3 !
;
Works ok.
Parser error occurs if the ending ; is on the same line.
--
Robert
SELECT : 1; -- returns e
Works, but gives a NOTICE that the : operator is depreciated and that
exp(x) should be used instead.
SELECT exp(1);
Gets ERROR: exp(INT4) does not exist.
SELECT exp(1.0);
Works fine of course.
Just seems strange that a depreciated operator actually works smoother.
--
16 matches
Mail list logo
