
> > 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 float8).

Yes, that sounds like a good plan for all scenarios that can follow !

> 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.

> 3. Eliminate most or all of the cross-numeric-type operators 
> (eg, there is no reason to support int2+int4 as a separate operator).

Yes.

> With this approach, an expression like "int4var = 42" would be initially
> typed as int4 and int2, but then the constant would be coerced to int4
> because int4=int4 is the closest-match operator.  (int2=int2 would not
> be considered because down-coercion isn't implicitly invokable.)  

It would fix the constants issue, yes. How about where int2col=int4col 
and it's indexability of int2col though ?

> Also
> we get more nearly SQL-standard behavior in expressions that combine
> numeric with float4/float8: the preferred type will be float, which
> accords with the spec's notions of exact numeric vs. 
> approximate numeric.

I do not understand the standard here.
Especially the following would seem awkward if that would switch to approximate:
set numericcol = numericcol * float4col; 

Andreas

Tue, 17 Sep 2002 11:00:07 +0200
"Zeugswetter Andreas SB SD" <ZeugswetterA@spardat.at>
Re: Proposal for resolving casting issues 
"Zeugswetter Andreas SB SD" <ZeugswetterA@spardat.at> 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, what?  That seems logically impossible to me ... or at least it
would reintroduce exactly the problem we need to get away from: casts
between float4, float8, numeric would be considered equally good in
either direction, creating ambiguity about which operator to use.
How are you envisioning it would work exactly?

Perhaps I should clarify what I had in mind: because the parser only
considers one level of type coercion when choosing a function or
assigning to a result column, it's actually necessary to have all thirty
cast combinations between the six numeric types available in pg_cast.
My notation "int2->int4->int8->numeric->float4->float8" is intended to
imply that of the thirty, these would be marked as implicitly coercible:

int2->int4
int2->int8
int2->numeric
int2->float4
int2->float8
int4->int8
int4->numeric
int4->float4
int4->float8
int8->numeric
int8->float4
int8->float8
numeric->float4
numeric->float8
float4->float8

while the fifteen reverse coercions would be assignment-only.

If we allow any circularity then we will have pairs of types with both
cast pathways marked as implicit, which will leave the parser unable to
choose which operator to use.  This is exactly why "numeric = float8"
has failed in past versions: there are two alternatives that are equally
easy to reach.


> It would fix the constants issue, yes. How about where int2col=int4col 
> and it's indexability of int2col though ?

See my other response.  The current scheme of using a cross-datatype
operator isn't helpful for indexing such cases anyway...

>> Also
>> we get more nearly SQL-standard behavior in expressions that combine
>> numeric with float4/float8: the preferred type will be float, which
>> accords with the spec's notions of exact numeric vs. 
>> approximate numeric.

> I do not understand the standard here.
> Especially the following would seem awkward if that would switch to
> approximate:
>	set numericcol = numericcol * float4col; 

Well, the spec's notion is that combining an "exact" number and an
"approximate" number must yield an "approximate" result.  This logic
is hard to argue with, even though in our implementation it would
seem to make more sense for numeric to be the top of the hierarchy
on range and precision grounds.

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 = numericcol * float4col::numeric;
which is sort of ugly; but no uglier than
	set float4col = float4col * numericcol::float4;
which is what you'd have to write if the system preferred numeric and
you wanted the other behavior.

I too have been thinking for a long time that I didn't like following
the spec's lead on this point; but I am now starting to think that it's
not all that bad.  This approach to handling constants is *much* cleaner
than what we've done in the past, or even any of the unimplemented
proposals that I can recall.  The behavior you'd get with combinations
of float and numeric variables is, well, debatable; from an
implementor's point of view preferring a numeric result makes sense,
but it's much less clear that users would automatically think the same.
Given the spec's position, I am starting to think that preferring float
is the right thing to do.

BTW, I am thinking that we don't need the notion of "preferred type" at
all in the numeric category if we use this approach.  I have not worked
through the details for the other type categories, but perhaps if we
adopt similar systems of one-way implicit promotions in each category,
we could retire "preferred types" altogether --- which would let us get
rid of hardwired type categories, too.

			regards, tom lane

Tue, 17 Sep 2002 10:05:29 -0400
Tom Lane <tgl@sss.pgh.pa.us>
Re: Proposal for resolving casting issues 
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 numericcol = numericcol * float4col::numeric;
> which is sort of ugly; but no uglier than
> 	set float4col = float4col * numericcol::float4;
> which is what you'd have to write if the system preferred numeric and
> you wanted the other behavior.

I need a clarification.  In the non-assignment case, does:

	WHERE numericcol = numericcol * 3.14159

evaluate "numericcol * 3.14159" as a numeric?

And does:

	WHERE 5.55 = numericcol * 3.14159

evaluate "numericcol * 3.14159" as a numeric too?

-- 
  Bruce Momjian                        |  http://candle.pha.pa.us
  pgman@candle.pha.pa.us               |  (610) 359-1001
  +  If your life is a hard drive,     |  13 Roberts Road
  +  Christ can be your backup.        |  Newtown Square, Pennsylvania 19073

Tue, 17 Sep 2002 15:14:41 -0400 (EDT)
Bruce Momjian <pgman@candle.pha.pa.us>
Re: Proposal for resolving casting issues
Bruce Momjian <pgman@candle.pha.pa.us> 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 "numericcol * 3.14159" as a numeric too?

Yup.  The context does not matter: when we have foo * bar, we are going
to decide which kind of * operator is meant without regard to
surrounding context.  It's very much a bottom-up process, and has to be.

			regards, tom lane

Tue, 17 Sep 2002 15:26:20 -0400
Tom Lane <tgl@sss.pgh.pa.us>
Re: Proposal for resolving casting issues 