Re: Range Types, constructors, and the type system - Mailing list pgsql-hackers

On Jun27, 2011, at 02:48 , Jeff Davis wrote:
> On Mon, 2011-06-27 at 00:56 +0200, Florian Pflug wrote:
>> Well, there actually *is* some precedence for that kind of top-down
>> (form a syntactic perspective) type inference. We *enforce* the cast
>> in 
>>  array[]::<arraytype>
>> and actually for a very similar reason - without the case, there's no
>> way of knowing which type of empty array was meant. I think we also
> 
> That's a good point.
> 
> Although, I'm not sure whether that's an argument that we can make the
> type system work as-is, or if it means that we should add syntax like
> ARRAY[].

It was meant as an argument for the former, i.e. for extending the type
system (or rather the function call syntax, as I argue below).

>> special-case
>>  'literal'::<type>
>> to use the input function of type directly, instead of first creating
>> a text value and later casting it to <type>.
> 
> That is certainly true. Quoted strings never start out as text, they
> start out as "unknown" and wait for the type inference to determine the
> type. I'm not entirely sure whether a quoted string followed by a cast
> is briefly unknown and then cast, or if it's directly interpreted using
> the cast's type input function.

It's at least labelled with type "unknown" for a while AFAIK.

> I don't know if that's a good example though because it's near the end
> of the line and there's no function call in between the arguments and
> the cast. It might get more complex with cases like:
> 
>  range(lower(range(1,2)),upper(range(1,2)))::int8range
> 
> but maybe that can be done more easily than I think?

I wouldn't take it that far. What I had in mind was to *only* support
the case where the cast directly follows the function call, i.e. the case f(...)::type

I view this more as an extension of the function call syntax than of
type inference. In other languages with polymorphism, there usually is
an explicit syntactic construct for specifying the type arguments to
a polymorphic function. For example, C++ you'd write make_range<int>(3,4)
to call the polymorphic function make_range() with it's (first)
type argument set to "int". I think of f(...)::type
as essentially the same thing, but re-using already existing syntax
instead of inventing new one. 

I just checked - we currently special case "array[]::type" in transformExpr()
by detecting the case of an array expression being the immediate child
of a cast expression. I suggest we do the same for "f(...)::type", i.e.
also special case a function call being the immediate child of a cast
expression and pass down the forced result type to the function call node.

Function call nodes would then usually ignore that passed-down result type,
except in the case of a polymorphic functions whose argument types don't
uniquely define its result type.

But I haven't tried doing that, so there might be stumbling block down
that road that I missed...

best regards,
Florian Pflug