Joe Abbate <j...@freedomcircle.com> writes:
> 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():
> Hmmm ... Well, I'm just doing the same thing as pg_dump, which in 9.2rc1
> still outputs the same as before, namely:
Well, evidently you're *not* doing the same thing as pg_dump.
A look at pg_dump says that what it does is to cast the column to
regprocedure, and then strip the argument types from that printout.
Perhaps some experimentation would be illuminating:
regression=# select 'upper'::regproc;
ERROR: more than one function named "upper"
LINE 1: select 'upper'::regproc;
^
regression=# select 'upper(text)'::regprocedure;
regprocedure
--------------
upper(text)
(1 row)
regression=# select 'upper(text)'::regprocedure::oid;
oid
-----
871
(1 row)
regression=# select 871::regprocedure;
regprocedure
--------------
upper(text)
(1 row)
regression=# select 871::regproc;
regproc
------------------
pg_catalog.upper
(1 row)
> 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?
What's physically in there is an OID (and so the casts above are no-ops
at the representational level). What we're discussing is the behavior
of the output function for the regproc or regprocedure types.
regards, tom lane
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
