Re: BUG #13053: type names pollute function name space - Mailing list pgsql-bugs

I figured it had something to do with array types, given the error, but =
still feel like creating the function, when it cannot be called, is an =
error. I would appreciate getting an error similar to the one you =
described instead of one later when attempting to call the function =
since I would have saved me a couple of hours of debugging. I would =
appreciate it if the documentation contained some hint that =
type-conversion functions were automatically created by prepending an =
underscore. (I don=E2=80=99t know how I would have found that nugget =
without a better error message but still feel it is missing.)

=20

I also tried the quoted-identifier trick and was equally surprised it =
didn=E2=80=99t work and then on reflection relieved that it =
didn=E2=80=99t either.

=20

We have solved the problem by changing our naming convention, given the =
usual momentum on projects like this I don=E2=80=99t expect it to be =
changed, but better documentation and an better error would be =
appreciated.

=20

From: David G. Johnston [mailto:david.g.johnston@gmail.com]=20
Sent: Tuesday, April 14, 2015 3:55 PM
To: dwayne.towell@gmail.com
Cc: pgsql-bugs@postgresql.org
Subject: Re: [BUGS] BUG #13053: type names pollute function name space

=20

On Tue, Apr 14, 2015 at 2:24 PM, <dwayne.towell@gmail.com =
<mailto: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 =
<mailto:dwayne.towell@gmail.com>=20
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 =
function
by finding an auto created(?) conversion(?) function.

=20

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

=20

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".

=20

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.

=20

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?

=20

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.

=20

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.

=20

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"...?

=20

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.

=20

David J.

=20