|From:||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|
Hello, this is the patchset v2 of this feature.
Adding regrole as the name says.
Adding regnamespace. This depends on 0001 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.
Documentation patch for this new types.
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.
NTT Open Source Software Center
|Next Message||Kyotaro HORIGUCHI||2015-02-18 08:44:40||Re: How about to have relnamespace and relrole?|
|Previous Message||Kyotaro HORIGUCHI||2015-02-18 08:34:41||Re: pg_basebackup may fail to send feedbacks.|