Re: How about to have relnamespace and relrole? - Mailing list pgsql-hackers

From Tom Lane
Subject Re: How about to have relnamespace and relrole?
Date
Msg-id 2540.1422976332@sss.pgh.pa.us
Whole thread Raw
In response to How about to have relnamespace and relrole?  (Kyotaro HORIGUCHI <horiguchi.kyotaro@lab.ntt.co.jp>)
Responses Re: How about to have relnamespace and relrole?
Re: How about to have relnamespace and relrole?
List pgsql-hackers
Kyotaro HORIGUCHI <horiguchi.kyotaro@lab.ntt.co.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



pgsql-hackers by date:

Previous
From: Marko Tiikkaja
Date:
Subject: Re: Release note bloat is getting out of hand
Next
From: Robert Haas
Date:
Subject: Re: Redesigning checkpoint_segments