Skip site navigation (1) Skip section navigation (2)

Re: pg_operator.oprcode in 9.2rc1

From: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
To: Joe Abbate <jma(at)freedomcircle(dot)com>
Cc: pgsql-hackers <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: pg_operator.oprcode in 9.2rc1
Date: 2012-08-30 18:56:03
Message-ID: 27380.1346352963@sss.pgh.pa.us (view raw or flat)
Thread:
Lists: pgsql-hackers
Joe Abbate <jma(at)freedomcircle(dot)com> writes:
> Yes, I suspected that an OID was stored.  What I'd still quibble with is
> the use of the ambiguous regproc in pg_operator (also pg_type) and the
> still-ambiguous schema-qualified proc name.  I guess it's not feasible
> (at least, short term), but it'd be preferable to store a "raw" OID and
> let the user cast to regprocedure (or change the 'regproc' to
> 'regprocedure').

Yeah, ideally those columns would be regprocedure.  There are
bootstrapping problems involved though with populating the initial
contents of the catalogs during initdb --- the regprocedure input
function doesn't work in that environment.  (It might be possible to
hack something for pg_operator, but the circularity is rather
fundamental for loading pg_type, since the input function would need to
consult pg_type to make sense of argument types.)

In the meantime I'd suggest casting the columns to regprocedure when
querying, if you want unambiguous results.  That's what pg_dump does.
Or you can cast to OID if you like numbers.

			regards, tom lane


In response to

pgsql-hackers by date

Next:From: Robert HaasDate: 2012-08-30 18:58:30
Subject: Re: Wiki link for max_connections? (Fwd: Re: [ADMIN] PostgreSQL oom_adj postmaster process to -17)
Previous:From: Joe AbbateDate: 2012-08-30 18:44:39
Subject: Re: pg_operator.oprcode in 9.2rc1

Privacy Policy | About PostgreSQL
Copyright © 1996-2014 The PostgreSQL Global Development Group