Re: How about to have relnamespace and relrole?

Поиск
Список
Период
Сортировка
От Tom Lane
Тема Re: How about to have relnamespace and relrole?
Дата
Msg-id 2540.1422976332@sss.pgh.pa.us
обсуждение исходный текст
Ответ на How about to have relnamespace and relrole?  (Kyotaro HORIGUCHI <horiguchi.kyotaro@lab.ntt.co.jp>)
Ответы Re: How about to have relnamespace and relrole?  (Kyotaro HORIGUCHI <horiguchi.kyotaro@lab.ntt.co.jp>)
Re: How about to have relnamespace and relrole?  (Robert Haas <robertmhaas@gmail.com>)
Список 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 по дате отправления:

Предыдущее
От: Marko Tiikkaja
Дата:
Сообщение: Re: Release note bloat is getting out of hand
Следующее
От: Robert Haas
Дата:
Сообщение: Re: Redesigning checkpoint_segments