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

Re: Implicit casts with generic arrays

From: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
To: Peter Eisentraut <peter_e(at)gmx(dot)net>
Cc: pgsql-hackers(at)postgresql(dot)org
Subject: Re: Implicit casts with generic arrays
Date: 2007-06-04 23:06:43
Message-ID: (view raw, whole thread or download thread mbox)
Lists: pgsql-hackers
I wrote:
> 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.

I've been experimenting with another solution, which is to not add any
weird error cases but instead add operators that will capture the
problem cases back away from the anyelement||anyarray operators.
My current prototype is

create function catany(text, anyelement) returns text as 
  $$ select $1 || $2::text $$ language sql;
create function catany(anyelement, text) returns text as 
  $$ select $1::text || $2 $$ language sql;

create operator || (procedure = catany, leftarg = text, rightarg = anyelement);
create operator || (procedure = catany, leftarg = anyelement, rightarg = text);

which seems to mostly do the "right" thing.  This approach would have
one nice property, namely eliminating the single biggest point of
push-back we are likely to get from removing the implicit casts to text.
I have no doubt that practically the only reasonable use-case for that
behavior was to let people concatenate stuff without being too picky
about casts, and this mostly preserves that ability.  It's not perfect,
because it only fixes cases in which at least one operand is either
unknown or implicitly coercible to text.  But in practice I think that
would cover 99% of cases, since typical usages tend to alternate
literals and data values.

Thoughts?  Is this too klugy for words?

			regards, tom lane

In response to


pgsql-hackers by date

Next:From: Tom LaneDate: 2007-06-05 01:11:44
Subject: Re: Performance regression on CVS head
Previous:From: Andrew DunstanDate: 2007-06-04 22:18:17
Subject: Re: syslogger line-end processing infelicity

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