Re: How about to have relnamespace and relrole?

From: Kyotaro HORIGUCHI <horiguchi(dot)kyotaro(at)lab(dot)ntt(dot)co(dot)jp>
To: Jim(dot)Nasby(at)BlueTreble(dot)com
Cc: tgl(at)sss(dot)pgh(dot)pa(dot)us, pgsql-hackers(at)postgresql(dot)org
Subject: Re: How about to have relnamespace and relrole?
Date: 2015-02-17 11:19:11
Message-ID: 20150217.201911.239516619.horiguchi.kyotaro@lab.ntt.co.jp
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

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

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Alexander Korotkov 2015-02-17 12:56:10 Re: GiST kNN search queue (Re: KNN-GiST with recheck)
Previous Message Kyotaro HORIGUCHI 2015-02-17 10:45:19 Re: pg_basebackup may fail to send feedbacks.