Hello Tom,
On 30/08/12 12:27, Tom Lane wrote:
> 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.
Hmmm ... Well, I'm just doing the same thing as pg_dump, which in 9.2rc1
still outputs the same as before, namely:
SET search_path = public, pg_catalog;
--
-- Name: +; Type: OPERATOR; Schema: public; Owner: -
--
CREATE OPERATOR + (
PROCEDURE = upper,
RIGHTARG = text
);
What's somewhat confusing is that the documentation (and \d pg_operator)
states oprcode (as well as oprrest and oprjoin) are of type 'regproc'
and that it references a pg_proc.oid. Does the catalog actually store
an OID, i.e., the OID of pg_catalog.upper(text), or something else?
Best regards,
Joe
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
