Re: Implicit casts with generic arrays - Mailing list pgsql-hackers

From Gregory Stark
Subject Re: Implicit casts with generic arrays
Date
Msg-id 87tztnl9lr.fsf@oxford.xeocode.com
Whole thread Raw
In response to Re: Implicit casts with generic arrays  (Tom Lane <tgl@sss.pgh.pa.us>)
Responses Re: Implicit casts with generic arrays  (Tom Lane <tgl@sss.pgh.pa.us>)
List pgsql-hackers
"Tom Lane" <tgl@sss.pgh.pa.us> writes:

> So after reflecting on all that, it doesn't seem like a good idea to
> hack the type-coercion code to discriminate against matching unknown
> to anyarray.  It looks to me like we have a very narrow problem and
> we should tailor a very narrow solution.  What I am currently thinking
> we should do is make oper() specifically test for the case of operator
> 349 with UNKNOWN left input, or operator 374 with UNKNOWN right input,
> and throw a custom error message hinting that the other operand
> needs to be cast to text.

Wouldn't that mean that 'foo'||'bar' would *still* fail?

It really seems to me that at some point down the line we're going to cave and
admit that users do expect 'foo' to be a string first and cast to other types
only if the context requires it. That would mean we should be considering
matching "unknown" as text first without casting and only if that fails
looking for other types.

--  Gregory Stark EnterpriseDB          http://www.enterprisedb.com



pgsql-hackers by date:

Previous
From: Heikki Linnakangas
Date:
Subject: Performance regression on CVS head
Next
From: "Jim C. Nasby"
Date:
Subject: Re: TOAST usage setting