Re: BUG #13053: type names pollute function name space

On Tue, Apr 14, 2015 at 2:24 PM, <dwayne.towell@gmail.com> wrote:

> The following bug has been logged on the website:
>
> Bug reference:      13053
> Logged by:          Dwayne Towell
> Email address:      dwayne.towell@gmail.com
> PostgreSQL version: 9.2.10
> Operating system:   CentOS
> Description:
>
> The following:
>
> =E2=80=8B=E2=80=8B
> CREATE TYPE x AS (id int);
> CREATE FUNCTION _x(text) RETURNS SETOF x AS $$ SELECT 1 WHERE $1=3D'hi'; =
$$
> LANGUAGE SQL;
> SELECT _x('hi');
>
> produces:
>
> ERROR:  array value must start with "{" or dimension information
> LINE 1: SELECT _x('hi');
>
> Which seems wrong. Creating a type named 'x' should not preempt my functi=
on
> by finding an auto created(?) conversion(?) function.
>

=E2=80=8BTo be more explicit about what is happening here=E2=80=8B:

It is finding the auto-magically created type "array x" aka: "x[]=E2=80=8B"=
.  For
reasons unknown to myself the underlying representation type is named "_x".

Then, since "type 'literal'" and "type('literal') are equivalent to
"'literal'::type", SELECT _x('literal') becomes ambiguous and its (_x)
treatment as a type precedes its treatment as a function name.

I'll admit it seems odd but I'd chalk this up to system oddity and move
on.  What is the solution you are looking for anyway?

I'm sure there are more surprises relating to types and functions since
functions are used to manipulate types - and as described above some
synatic sugar is involved as well - and maybe they could be better
documented...but I'm not see where preventing the creation of either the
function or the type (whichever is created last) is a viable solution and
I'm not seeing that the current rule of using the implied type cast
function first is necessarily wrong.

I would have thought that maybe you could access the original function
using double-quotes: SELECT "_x"('hi'); but that appears to be
incorrect...and not obviously useful even if it worked.

FWIW in the example provided I would prefer to have the CREATE FUNCTION
call fail with a "function already exists" error - though I do not believe
that is strictly correct.  Maybe "unsupported function signature - matching
array of type x already exists"...?

Not that I could fix this even if I wanted to but the effort compared to
the number of complaints is not favorable to any change being forthcoming.
That includes documentation though that is more likely if someone even puts
forth a rough suggestion for what such an improvement would look like.

David J.