Re: problem with bytea and undecorated literals

On Thu, Apr 29, 2010 at 01:59:04PM +0100, Daniele Varrazzo wrote:

> Well, Postgres does some educate guessing: when some text is passed as
> argument to a function and no signature exists for a text argument,
> Postgres does look for a datatype into which the argument can be
> casted:
> 
> test=> create function haveadate(x timestamp) returns text language sql
>  as $$ select 'got a ts'::text $$;
> CREATE FUNCTION
> test=> select haveadate ('2010-01-01');
>  haveadate
> -----------
>  got a ts
> (1 row)

In this case PostgreSQL does not have to guess the target
datatype: it is timestamp without ambiguity. So it tries to
cast whatever it receives into timestamp.

> This doesn't work in Peter's example because a function accepting a
> text argument exists, shadowing the one the caller wanted to invoke.

In Peter's example there were two candidates: cast
"something" to text or cast "something" to bytea. No way for
PG to know which was intended.

> With arrays instead it seems Postgres is not so aggressive in casting
> the argument to one for which a signature is available:
> 
> test=> create function haveadatea(x timestamp[]) returns text language sql
>  as $$ select 'got a ts[]'::text $$;
> CREATE FUNCTION
> test=> select haveadatea (array['2010-01-01']);
> ERROR:  function haveadatea(text[]) does not exist
> LINE 1: select haveadatea (array['2010-01-01']);
>                ^
> HINT:  No function matches the given name and argument types. You
> might need to add explicit type casts.

I agree this seems at the same guess level as
haveadate(text). Probably, the array is taking precedence
here:: when creating the array PG probably doesn't like
arrays of "somethings" so it casts "somethings" to text. If
this happens before the search for the function is commenced
PG won't know anymore that those somethings could have been
casted to timestamps as well.

> So a cast is required even in places where the text representation of
> the argument would have worked for non-array case:
> 
> test=> select haveadatea (array['2010-01-01'::timestamp]);
>  haveadatea
> ------------
>  got a ts[]
> (1 row)
> 
> test=> select haveadatea (array['2010-01-01']::timestamp[]);
>  haveadatea
> ------------
>  got a ts[]
> (1 row)

I see your point.

It's probably due to PG not trying to carry over
typelessness from array creation into function search.

Karsten
-- 
GPG key ID E4071346 @ wwwkeys.pgp.net
E167 67FD A291 2BEA 73BD  4537 78B9 A9F9 E407 1346