Re: How about to have relnamespace and relrole?

From: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
To: Kyotaro HORIGUCHI <horiguchi(dot)kyotaro(at)lab(dot)ntt(dot)co(dot)jp>
Cc: pgsql-hackers(at)postgresql(dot)org
Subject: Re: How about to have relnamespace and relrole?
Date: 2015-02-03 15:12:12
Message-ID: 2540.1422976332@sss.pgh.pa.us
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

Kyotaro HORIGUCHI <horiguchi(dot)kyotaro(at)lab(dot)ntt(dot)co(dot)jp> writes:
> Most of OID types has reg* OID types. Theses are very convenient
> when looking into system catalog/views, but there aren't OID
> types for userid and namespace id.

> What do you think about having these new OID types?

I'm not really excited about that. That line of thought would imply
that we should have "reg*" types for every system catalog, which is
surely overkill.

The existing reg* types were chosen to handle the cases where objects have
schema-qualified (and/or type-overloaded) names so that correct lookup is
not merely a matter of (select oid from pg_foo where name = 'bar') or
vice versa.

I think the policy is, or should be, that we create reg* types for exactly
the cases where lookup isn't that simple.

In particular, both of the cases you mention are hardly "new". They
existed when we made the current set of reg* types and were consciously
not added then.

> SELECT relnamespace::regnamespace, relname, relowner::regrole
> FROM pg_class WHERE relnamespace = 'public'::regnamespace;

Two reasons this isn't terribly compelling are (1) it's creating a
join in a place where the planner can't possibly see it and optimize
it, and (2) you risk MVCC anomalies because the reg* output routines
would not be using the same snapshot as the calling query.

We already have problem (2) with the existing reg* functions so I'm
not that excited about doubling down on the concept.

regards, tom lane

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Robert Haas 2015-02-03 15:19:22 Re: Redesigning checkpoint_segments
Previous Message Marko Tiikkaja 2015-02-03 15:11:57 Re: Release note bloat is getting out of hand