"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';
pronam
gt; To: Tom Lane; Zeugswetter Andreas SB SD
> Cc: 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 u
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
Chr
"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 0.0
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
> > > > 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
>
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
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
> > sa
> > 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 floa
"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
> "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
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...)
re
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 ].
CR
Tom Lane writes:
> On looking more closely, SQL99 appears to define user-defined casts as
> invocable *only* in explicit cast and assignment contexts.
> This seems to mean that we can get away with defining AS ASSIGNMENT to
> mean my second category (implicit in assignment only), and then pickin
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)---
T
I wrote:
> [Peter wrote:]
>> time -> interval: I'm not even sure this cast should exist at all.
>> Proper arithmetic would be IntervalValue = TimeValue - TIME 'midnight'.
>> At least make it non-implicit.
> I'd go along with marking it assignment-only.
I started to make this change, but have mo
"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 variabl
> > 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
>
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
>
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
>
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 CREAT
"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
"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:
> 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 pr
> > 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 (no
> 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
> 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.
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
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 i
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 implicit/e
31 matches
Mail list logo
