[ moving thread to a more appropriate list ]
Joe Conway <mail@joeconway.com> writes:
> Tom Lane wrote:
>> select 'GRANT EXECUTE ON ' || 1142::regprocedure;
>> ERROR: array value must start with "{" or dimension information
>>
>> BTW, it seems like there's something pretty broken here. How did
>> arrays get into it?
> regression=# \df array_append
> List of functions
> Result data type | Schema | Name | Argument data types
> -------------------+------------+--------------+----------------------
> anyarray | pg_catalog | array_append | anyarray, anyelement
> (1 row)
> So the "||" operator sees (unknown, regprocedure), and make_op tries to
> coerce the unknown literal to an array of regprocedure, which of course
> fails. If instead the literal is explicitly cast:
> select 'GRANT EXECUTE ON '::text || 1142::regprocedure;
> ERROR: operator does not exist: text || regprocedure
> HINT: No operator matches the given name and argument type(s). You may
> need to add explicit type casts.
> I'm not clear on how we can do better :(. Any suggestions?
I'm not sure either, but I can't say that I like this interpretation.
I did find that if there is an implicit coercion to text then the system
will prefer a saner interpretation:
regression=# select 'GRANT EXECUTE ON ' || 1142::regprocedure;
ERROR: array value must start with "{" or dimension information
regression=# create function text(regprocedure) returns text as '
regression'# begin
regression'# return $1;
regression'# end' language plpgsql stable strict;
CREATE FUNCTION
regression=# create cast (regprocedure as text) with function text(regprocedure) as implicit;
CREATE CAST
regression=# select 'GRANT EXECUTE ON ' || 1142::regprocedure; ?column?
-----------------------------------------GRANT EXECUTE ON date_mii(date,integer)
(1 row)
I'm worried though about how stable this choice is. I'm almost tempted
to add a wart in the coercion routines to discourage matching "unknown"
to "anyarray" ...
regards, tom lane