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-05 17:02:28
Message-ID: (view raw or whole thread)
Lists: pgsql-hackers
I wrote:
> 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've been testing this approach more, and finding that it really
captures a bit too much: some cases that you'd prefer went to
anyelement||anyarray will be captured by the text||anyelement operator.
For example in 8.2 this is mapped to array_prepend:

regression=# select 'x'::text || array['aa','bb','cc'];
(1 row)

but with the experimental code you get textcat:

catany=# select 'x'::text || array['aa','bb','cc'];
(1 row)

Basically the textcat operators will capture any case where the scalar
side is implicitly coercible to text, because the type resolution rules
will prefer that.  There are some hacks we could make to make this less
probable (eg, declare the capturing operators as taking varchar instead
of text) but I can't find any complete solution short of changing the
resolution rules themselves.  Which I'm loath to do since it might have
unexpected side-effects.

What I would like to propose is that we deprecate use of || as the
operator name for array_prepend and array_append, and invent new
recommended names for them.  As I said earlier, these operators
aren't exactly concatenation in any normal sense anyway, since they
don't treat their operands symmetrically.  My first thought is to
suggest using the shifting symbols:
		anyelement >> anyarray
		anyarray << anyelement
but perhaps someone will have a better suggestion.  If we do that, then
we have a solution for anyone whose array prepend or append operator is
unexpectedly captured by text concatenation: use the new names instead.

Now this is only going to seem like a good idea if you agree that we
should have some capturing operators like these.  But if we don't,
I think we are going to get a lot of push-back from people whose
concatenations of random datatypes suddenly stopped working.
Essentially this proposal is putting the compatibility hit of tightening
the implicit cast rules onto people who are using array append/prepend
instead of people who are using concatenation without explicit casts.
I think there are a lot fewer of the former than the latter.


			regards, tom lane

In response to


pgsql-hackers by date

Next:From: Andrew HammondDate: 2007-06-05 17:52:39
Subject: Re: Command tags in create/drop scripts
Previous:From: Alvaro HerreraDate: 2007-06-05 16:19:50
Subject: Re: Command tags in create/drop scripts

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