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

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’t know how I would have found that nugget without a better error message but still feel it is missing.)

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

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

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

On Tue, Apr 14, 2015 at 2:24 PM, <dwayne(dot)towell(at)gmail(dot)com <mailto:dwayne(dot)towell(at)gmail(dot)com> > wrote:

The following bug has been logged on the website:

Bug reference: 13053
Logged by: Dwayne Towell
Email address: dwayne(dot)towell(at)gmail(dot)com <mailto:dwayne(dot)towell(at)gmail(dot)com>
PostgreSQL version: 9.2.10
Operating system: CentOS
Description:

The following:

​​

CREATE TYPE x AS (id int);
CREATE FUNCTION _x(text) RETURNS SETOF x AS $$ SELECT 1 WHERE $1='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.

​To be more explicit about what is happening here​:

It is finding the auto-magically created type "array x" aka: "x[]​". 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.