Re: pg_operator.oprcode in 9.2rc1

Joe Abbate <jma(at)freedomcircle(dot)com> writes:
> Hello hackers,
> I've been testing Pyrseas against 9.2rc1. A test that does a CREATE
> OPERATOR is giving a small difference. Specifically, the test issues
> the statement:

> CREATE OPERATOR + (PROCEDURE = upper, RIGHTARG = text);

> Pyrseas then queries the pg_operator catalog to map the procedure for
> output. Selecting oprcode in 8.4, 9.0, and 9.1, always returns 'upper',
> but in 9.2rc1, the value is 'pg_catalog.upper'. It does not matter
> whether pg_catalog is on the search_path or not.

The reason for the difference is that in 9.2 there's more than one
pg_catalog.upper():

regression=# \df upper
List of functions
Schema | Name | Result data type | Argument data types | Type
------------+-------+------------------+---------------------+--------
pg_catalog | upper | anyelement | anyrange | normal
pg_catalog | upper | text | text | normal
(2 rows)

whereas prior versions had only upper(text). The regproc output
function isn't allowed to print argument types, which is what would be
needed to disambiguate altogether, but it does what it can to warn you
that "upper" alone is not a unique name by schema-qualifying the name.

This is not new behavior in 9.2, it just happens to occur for upper()
when it did not before. If you're expecting regproc to always return
unique unqualified names then your code is broken anyway, since such
a requirement cannot be met when the function is overloaded.

regards, tom lane