Re: proposal: regrole type?

2012/12/25 Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>:
> Pavel Stehule <pavel(dot)stehule(at)gmail(dot)com> writes:
>> Can we implement REGROLE type, that simplify role name <-> oid transformations?
>
> Why? It's not any more complicated than it is for the other object
> types that lack REGxxx pseudotypes. Generally speaking, we've only
> bothered with pseudotypes for the cases where lookup is not trivial,
> eg because there are search path considerations.

my first motivation was a cosiness, but a second view shows so this
type(s) can be useful:

* It is relative natural - and can simplify and speed up some kind of
queries, because it directly access to cache.

* We can reduce to half lot of functions \df has_* (84 functions)

pg_catalog | pg_has_role | boolean | name, name, text | normal
pg_catalog | pg_has_role | boolean | name, oid, text | normal
pg_catalog | pg_has_role | boolean | name, text | normal
pg_catalog | pg_has_role | boolean | oid, name, text | normal
pg_catalog | pg_has_role | boolean | oid, oid, text | normal
pg_catalog | pg_has_role | boolean | oid, text | normal

these function should be replaced with more semantics descriptive headers

pg_has_role(regrole, regrole, text)
pg_has_role(regrole, text)
pg_has_role(text)

so we can drop (42 functions from catalog)

* this new datatype can be used in custom functions with implicit
validity checking - and if I can sort a importance of some internal
objects - then the roles are relative on high position.

Best regards

Pavel

p.s. A implementation should be little bit harder than I expected due
specific role "public", but I am thinking so it can has a some value.

>
> regards, tom lane