Re: How about to have relnamespace and relrole?

Hello, this is the patchset v2 of this feature.

0001-Add-regrole.patch
Adding regrole as the name says.

0002-Add-regnamespace.patch
Adding regnamespace. This depends on 0001 patch.

0003-Check-new-reg-types-are-not-used-as-default-values.patch
Inhibiting the new OID aliss types from being used as constants
in default values, which make dependencies on the other
(existing) OID alias types.

0004-Documentation-for-new-OID-alias-types.patch
Documentation patch for this new types.

regards,

At Tue, 17 Feb 2015 20:19:11 +0900 (Tokyo Standard Time), Kyotaro HORIGUCHI <horiguchi(dot)kyotaro(at)lab(dot)ntt(dot)co(dot)jp> wrote in <20150217(dot)201911(dot)239516619(dot)horiguchi(dot)kyotaro(at)lab(dot)ntt(dot)co(dot)jp>
> 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.

--
Kyotaro Horiguchi
NTT Open Source Software Center