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

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
constantsin 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.kyotaro@lab.ntt.co.jp> wrote in
<20150217.201911.239516619.horiguchi.kyotaro@lab.ntt.co.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.Nasby@BlueTreble.com> wrote in <54DD3358.9030601@BlueTreble.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