Josh Berkus writes:
> The root cause of this is that we treat "default TEXT" the same as "real
> TEXT" as a type.
No, we do not do that at all. A NULL is initially of type unknown, and
that is definitely not the same as text. The type resolution rules
treat the two cases differently.
The real
David,
> 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".
Well, that's not how "anyel
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 mis
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 su
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
On Fri, Jul 12, 2013 at 8:47 AM, Benedikt Grundmann
wrote:
> A third party application we use generates SQL queries. Here is query it
> generated that broke today and for which I have a hard time arguing that the
> postgres behavior is correct (minimally the error message is confusing):
>
> =# cr
Benedikt Grundmann wrote
> A third party application we use generates SQL queries. Here is query it
> generated that broke today and for which I have a hard time arguing that
> the postgres behavior is correct (minimally the error message is
> confusing):
>
> =# create temporary table foo (b doub
A third party application we use generates SQL queries. Here is query it
generated that broke today and for which I have a hard time arguing that
the postgres behavior is correct (minimally the error message is confusing):
=# create temporary table foo (b double precision );
CREATE TABLE
Time: 40
