Re: How about to have relnamespace and relrole?

From: Andrew Dunstan <andrew(at)dunslane(dot)net>
To: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
Cc: Kyotaro HORIGUCHI <horiguchi(dot)kyotaro(at)lab(dot)ntt(dot)co(dot)jp>, Jim(dot)Nasby(at)BlueTreble(dot)com, andres(at)2ndquadrant(dot)com, robertmhaas(at)gmail(dot)com, pgsql-hackers(at)postgresql(dot)org
Subject: Re: How about to have relnamespace and relrole?
Date: 2015-03-31 19:52:45
Message-ID: 551AFB0D.2070000@dunslane.net
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers


On 03/29/2015 02:55 PM, Tom Lane wrote:
> Andrew Dunstan <andrew(at)dunslane(dot)net> writes:
>> I have just claimed this as committer in the CF, but on reviewing the
>> emails it looks like there is disagreement about the need for it at all,
>> especially from Tom and Robert.
>> I confess I have often wanted regnamespace, particularly, and
>> occasionally regrole, simply as a convenience. But I'm not going to
>> commit it against substantial opposition.
>> Do we need a vote?
> My concern about it is basically that I don't see where we stop.
> The existing regFOO alias types are provided for object classes which
> have nontrivial naming conventions (schema qualification, overloaded
> argument types, etc), so that you can't just do "select ... from
> catalog where objectname = 'blah'". That doesn't apply to namespaces
> or roles. So I'm afraid that once this precedent is established,
> there will be demands for regFOO for every object class we have,
> and I don't want that much clutter.
>
> It may be that these two cases are so much more useful than any other
> conceivable cases that we can do them and stop, but I don't think that
> argument has been made convincingly.

Well, here's a list of all the fooname attributes in the catalog, which
I guess are the prime candidates for regfoo pseudotypes. Besides those
we already have and the two proposed here, I'm not sure there will be
huge demand for others - tablespace maybe, trigger doesn't seem very
practicable, and I could just see suggestions for collation and
conversion, but those seem pretty marginal, and that seems to be about
it, to me.

attrelid | attname
--------------------------------------------+--------------------------
pg_proc | proname
pg_type | typname
pg_attribute | attname
pg_class | relname
pg_constraint | conname
pg_operator | oprname
pg_opfamily | opfname
pg_opclass | opcname
pg_am | amname
pg_language | lanname
pg_rewrite | rulename
pg_trigger | tgname
pg_event_trigger | evtname
pg_namespace | nspname
pg_conversion | conname
pg_database | datname
pg_tablespace | spcname
pg_pltemplate | tmplname
pg_authid | rolname
pg_ts_config | cfgname
pg_ts_dict | dictname
pg_ts_parser | prsname
pg_ts_template | tmplname
pg_extension | extname
pg_foreign_data_wrapper | fdwname
pg_foreign_server | srvname
pg_policy | polname
pg_collation | collname

cheers

andrew

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Andreas Karlsson 2015-03-31 20:00:34 Move inet_gist to right place in pg_amproc
Previous Message Tom Lane 2015-03-31 19:40:17 Re: clang -fsanitize=undefined error in ecpg