Re: How about to have relnamespace and relrole?

Hello, thank you for the comment.

The current patch lacks change in documentation and dependency
stuff. Current framework doesn't consider changing pg_shdepend
from column default expressions so the possible measures are the
followings, I think.

1. Make pg_shdepend to have refobjsubid and add some deptypes of
pg_depend, specifically DEPENDENCY_NORMAL is needed. Then,
change the dependency stuff.

2. Simplly inhibit specifying them in default
expressions. Integer or OID can act as the replacement.

=# create table t1 (a int, b regrole default 'horiguti'::regrole);
ERROR: Type 'regrole' cannot have a default value

1 is quite overkill but hardly seems to be usable. So I will go
on 2 and post additional patch.

At Thu, 12 Feb 2015 17:12:24 -0600, Jim Nasby <Jim(dot)Nasby(at)BlueTreble(dot)com> wrote in <54DD3358(dot)9030601(at)BlueTreble(dot)com>
> On 2/12/15 5:28 AM, Kyotaro HORIGUCHI wrote:
> > Hello, I changed the subject.

# Ouch! the subject remaines wrong..

> > 1. Expected frequency of use
> ...
> > For that reason, although the current policy of deciding whether
> > to have reg* types seems to be whether they have schema-qualified
> > names, I think regrole and regnamespace are valuable to have.
>
> Perhaps schema qualification was the original intent, but I think at
> this point everyone uses them for convenience. Why would I want to
> type out JOIN pg_namespace n ON n.oid = blah.???namespace when I could
> simply do ???namespace::regnamespace?

Yes, that is the most important point of this patch.

> > 2. Anticipaed un-optimizability
> >
> > Tom pointed that these reg* types prevents planner from
> > optimizing the query, so we should refrain from having such
> > machinary. It should have been a long-standing issue but reg*s
> > sees to be rather faster than joining corresponding catalogs
> > for moderate number of the result rows, but this raises another
> > more annoying issue.
> >
> >
> > 3. Potentially breakage of MVCC
> >
> > The another issue Tom pointed is potentially breakage of MVCC by
> > using these reg* types. Syscache is invalidated on updates so
> > this doesn't seem to be a problem on READ COMMITTED mode, but
> > breaks SERIALIZABLE mode. But IMHO it is not so serious problem
> > as long as such inconsistency occurs only on system catalog and
> > it is explicitly documented togethee with the un-optimizability
> > issue. I'll add a patch for this later.
>
> The way I look at it, all these arguments went out the window when
> regclass was introduced.
>
> The reality is that reg* is *way* more convenient than manual
> joins. The arguments about optimization and MVCC presumably apply to
> all reg* casts, which means that ship has long since sailed.

I agree basically, but I think some caveat is needed. I'll
include that in the coming documentation patch.

> If we offered views that made it easier to get at this data then maybe
> this wouldn't matter so much. But DBA's don't want to join 3 catalogs
> together to try and answer a simple question.

It has been annoying me these days.

regards,

--
Kyotaro Horiguchi
NTT Open Source Software Center