Zeugswetter Andreas SB SD [EMAIL PROTECTED] writes:
Note that if you write, say,
set numericcol = numericcol * 3.14159;
my proposal would do the right thing since the constant would be typed
as numeric to start with and would stay that way. To do what you want
with a float variable,
Zeugswetter Andreas SB SD [EMAIL PROTECTED] writes:
Yes, that is the case where the new behavior would imho not be good (but you
say spec compliant). I loose precision even though there is room to hold it.
Lose what precision? It seems silly to imagine that the product of
Have you seen
Yes, that is the case where the new behavior would imho not be good (but you
say spec compliant). I loose precision even though there is room to hold it.
Lose what precision? It seems silly to imagine that the product of
Have you seen my example ? If calculated in float4 the
On Thu, Sep 19, 2002 at 04:57:30PM +0200, Zeugswetter Andreas SB SD wrote:
Have you seen my example ? If calculated in float4 the result of
1.01*1000.0-1000.0 would be 0.0, no ?
So? If you are storing one input as float4, then you cannot rationally
say that you
On Thu, Sep 19, 2002 at 10:30:51AM -0500, Ross J. Reedstrom wrote:
Ah, sorry to drag this on, then. But this is one of those clear cases
were we must fo the right thing, not follow the crowd. PostgreSQL gets
do
used by a lot of scientific projects (Have you noticed all the big
Have you seen my example ? If calculated in float4 the result of
1.01*1000.0-1000.0 would be 0.0, no ?
So? If you are storing one input as float4, then you cannot rationally
say that you know the result to better than 6 digits, because you don't
know the input
On Thu, Sep 19, 2002 at 06:00:37PM +0200, Zeugswetter Andreas SB SD wrote:
What if he must display 9 digits and says the result is approximately 2.45678932
would that be worse than 2.4600 ?
Yup. Trailing zeros are not significant. That's why scientific notation is nice:
you don't fill
Zeugswetter Andreas SB SD [EMAIL PROTECTED] writes:
For above calculation pg will in the future return 0. as an
answer to 1.01*1000.0-1000.0 when used in my example context, while
it currently returns 0.0010 ...
You both are saying, that
Will the new casting stuff address this kind of annoyance?
usa=# select average(octet_length(val)) from users_sessions;
ERROR: Function 'average(int4)' does not exist
Unable to identify a function that satisfies the given argument
types
You may need to add explicit typecasts
: Bruce Momjian; [EMAIL PROTECTED]
Subject: Re: [HACKERS] Proposal for resolving casting issues
Will the new casting stuff address this kind of annoyance?
usa=# select average(octet_length(val)) from users_sessions;
ERROR: Function 'average(int4)' does not exist
Unable to identify
Christopher Kings-Lynne [EMAIL PROTECTED] writes:
Will the new casting stuff address this kind of annoyance?
usa=# select average(octet_length(val)) from users_sessions;
ERROR: Function 'average(int4)' does not exist
regression=# select * from pg_proc where proname = 'average';
proname |
Note that if you write, say,
set numericcol = numericcol * 3.14159;
my proposal would do the right thing since the constant would be typed
as numeric to start with and would stay that way. To do what you want
with a float variable, it'd be necessary to write
set numericcol =
Zeugswetter Andreas SB SD [EMAIL PROTECTED] writes:
Note that if you write, say,
set numericcol = numericcol * 3.14159;
my proposal would do the right thing since the constant would be typed
as numeric to start with and would stay that way. To do what you want
with a float variable, it'd be
Bruce Momjian writes:
Or possibly it should be AS IMPLICIT?
I think AS IMPLICIT would be better because we have other AS [var]
clauses.
But IMPLICIT is not a variable.
--
Peter Eisentraut [EMAIL PROTECTED]
---(end of broadcast)---
TIP
Peter Eisentraut wrote:
Bruce Momjian writes:
Or possibly it should be AS IMPLICIT?
I think AS IMPLICIT would be better because we have other AS [var]
clauses.
But IMPLICIT is not a variable.
I meant we have cases where we do AS [ keyword1 | keyword2 ].
CREATE
Bruce Momjian [EMAIL PROTECTED] writes:
What I am saying is that is better to do AS [ keyword | keyword ] rather
than [ AS keyword | keyword ].
Yeah, I thought the same after looking at it a little. Committed that
way (of course it's still open to adjustment...)
Tom Lane wrote:
We've been discussing this stuff in fits and starts for months now, but
nothing satisfactory has been arrived at. I've concluded that part of
the problem is that we are trying to force the system's behavior into
a model that is too limiting: we need more than an
Tom Lane wrote:
Zeugswetter Andreas SB SD [EMAIL PROTECTED] writes:
I think the following three states may enable a closer match to an actually
desired (Peter said mandated by SQL99) behavior.
1. okay as implicit cast in expression or assignment
2. okay as implicit cast in expression
What I will do instead is adjust parse_coerce.c so that a
length-coercion function can have either of the signatures
foo(foo,int4) returns foo
or
foo(foo,int4,bool) returns foo
and then modify the above-mentioned length coercion functions to provide
the desired behavior. This
Bruce Momjian [EMAIL PROTECTED] writes:
I think there is some confusion here. The runtime checks Andreas was
talking about was allowing a double of 64.0 to cast to an int4 while
disallowing 64.1 from being cast to an int4 because it is not a hole
number.
I am not sure doubles have enough
For numbers there is probably only the solution to invent an
anynumber generic type.
Actually, I had been toying with the notion of doing the following:
1. A numeric literal is initially typed as the smallest type that will
hold it in the series int2, int4, int8, numeric (notice NOT
I think there is some confusion here. The runtime checks Andreas was
talking about was allowing a double of 64.0 to cast to an int4 while
disallowing 64.1 from being cast to an int4 because it is not a hole
number.
Yes, and Tom's proposal for numbers is sufficient for constants, since
Zeugswetter Andreas SB SD [EMAIL PROTECTED] writes:
When those are really truncated ESQL/C needs to set a warning in sqlca.sqlwarn
though, thus I think the second signature should also have an output flag to tell
whether truncation actually occurred.
Maybe this should be kept for a protocol
Zeugswetter Andreas SB SD [EMAIL PROTECTED] writes:
It is not sufficient for the optimizer for joins though, since it
cannot use the int4 index when confronted with where tab1.int4col =
tab2.numericcol.
For cross-datatype joins, the proposal as I sketched it would result in
the parser
Zeugswetter Andreas SB SD [EMAIL PROTECTED] writes:
2. Allow implicit up-coercion int2-int4-int8-numeric-float4-float8,
but down-coercions aren't implicit except for assignment.
How about int2-int4-int8-numeric-float4-float8-numeric ?
That would also allow an upward path from float8.
Uh,
I wrote:
I think we must extend pg_cast's castimplicit column to a three-way value:
* okay as implicit cast in expression (or in assignment)
* okay as implicit cast in assignment only
* okay only as explicit cast
Question: what shall we call these alternatives in CREATE
Tom Lane wrote:
I favor using IMPLICIT, which would make the syntax of CREATE CAST be
CREATE CAST (sourcetype AS targettype)
WITH FUNCTION funcname (argtype)
[ AS ASSIGNMENT | IMPLICIT ]
CREATE CAST (sourcetype AS targettype)
WITHOUT FUNCTION
Tom Lane wrote:
Note that if you write, say,
set numericcol = numericcol * 3.14159;
my proposal would do the right thing since the constant would be typed
as numeric to start with and would stay that way. To do what you want
with a float variable, it'd be necessary to write
set
Bruce Momjian [EMAIL PROTECTED] writes:
I need a clarification. In the non-assignment case, does:
WHERE numericcol = numericcol * 3.14159
evaluate numericcol * 3.14159 as a numeric?
Yup (given my proposed changes that is).
And does:
WHERE 5.55 = numericcol * 3.14159
evaluate
29 matches
Mail list logo
