Josh Berkus wrote
> On 07/12/2013 07:28 AM, Benedikt Grundmann wrote:
>> Thanks David,
>>
>> I like the fact that postgres is explicit in it's types. All I'm arguing
>> is that error message is misleading. And that I had a hard time
>> understanding why happened what happened. The part I was missing is that
>> despite supporting an any type the necessary type inference is very very
>> local and quickly resorts to the default type.
>
> 2. you call min(). Min() works for many datatypes. Min() says: "can I
> work for text?" The answer is "yes", so at this point the NULL which
> was "default text" becomes *really* text.
>
> .
> .
> .
>
> The alternative would be to disallow unadorned NULLs entirely, which
> would break thousands of applications.
In the absence of the function call the system is able to delay resolving
the type until later in the query:
SELECT *
FROM (VALUES ('2013-02-01'::date), ('2013-01-01'), (NULL) ) vals (col1);
--works
SELECT *
FROM (VALUES ('2013-02-01'::date), ('2013-01-01'), (min(NULL)) ) vals
(col1); --fails
I have no idea how this mechanism works but ISTM that the planner could, for
"anyelement", look at where the result of the function call is used and add
a cast to the function input value to match the desired result type if the
input type is "undefined".
I'm curious what you would consider to be a "more apropos error message" in
this situation; regardless of how difficult it would be to implement.
I am also curious if you can think of a better example of where this
behavior is problematic. The query for this thread is not something that I
would deem to be good SQL.
David J.
--
View this message in context:
http://postgresql.1045698.n5.nabble.com/column-b-is-of-type-X-but-expression-is-of-type-text-tp5763586p5763615.html
Sent from the PostgreSQL - hackers mailing list archive at Nabble.com.