Skip site navigation (1) Skip section navigation (2)

Re: Implicit casts with generic arrays

From: Gregory Stark <stark(at)enterprisedb(dot)com>
To: "Tom Lane" <tgl(at)sss(dot)pgh(dot)pa(dot)us>
Cc: "Peter Eisentraut" <peter_e(at)gmx(dot)net>, <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: Implicit casts with generic arrays
Date: 2007-06-04 20:59:12
Message-ID: 87tztnl9lr.fsf@oxford.xeocode.com (view raw or flat)
Thread:
Lists: pgsql-hackers
"Tom Lane" <tgl(at)sss(dot)pgh(dot)pa(dot)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


In response to

Responses

pgsql-hackers by date

Next:From: Jim C. NasbyDate: 2007-06-04 21:18:03
Subject: Re: TOAST usage setting
Previous:From: Heikki LinnakangasDate: 2007-06-04 20:36:11
Subject: Performance regression on CVS head

Privacy Policy | About PostgreSQL
Copyright © 1996-2014 The PostgreSQL Global Development Group