|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>|
|Subject:||Re: How about to have relnamespace and relrole?|
|Views:||Raw Message | Whole Thread | Download mbox | Resend email|
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
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
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
|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|