Re: How about to have relnamespace and relrole?

From: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
To: Andrew Dunstan <andrew(at)dunslane(dot)net>
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 20:48:18
Message-ID: 26969.1427834898@sss.pgh.pa.us
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

Andrew Dunstan <andrew(at)dunslane(dot)net> writes:
> On 03/29/2015 02:55 PM, Tom Lane wrote:
>> 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.

Hmm. We can ignore pg_attribute and pg_pltemplate, which don't have OIDs
and thus aren't candidates anyway. And we can ignore the ones
corresponding to the already-existing regFOO types. That leaves

> pg_am | amname
> pg_authid | rolname (*)
> pg_collation | collname
> pg_constraint | conname
> pg_conversion | conname
> pg_database | datname
> pg_event_trigger | evtname
> pg_extension | extname
> pg_foreign_data_wrapper | fdwname
> pg_foreign_server | srvname
> pg_language | lanname
> pg_namespace | nspname (*)
> pg_opclass | opcname
> pg_opfamily | opfname
> pg_policy | polname
> pg_rewrite | rulename
> pg_tablespace | spcname
> pg_trigger | tgname
> pg_ts_parser | prsname
> pg_ts_template | tmplname

of which the proposed patch covers the two starred ones.

OTOH, looking at this list, there are already numerous cases where
the object identity is more than just a name (eg, collations have
schema-qualified names, opfamilies are not only schema-qualified
but are per-index-AM as well, triggers and constraints are named
per-table, etc). So it's clear that we've already been applying
a "usefulness" criterion rather than just "does it have a
multi-component name" when choosing which objects to provide
regFOO types for.

In view of that, you could certainly argue that if someone's bothered
to make a patch to add a new regFOO type, it's useful enough. I don't
want to end up with thirtysomething of them, but we don't seem to be
trending in that direction.

Or in short, objection withdrawn. (As to the concept, anyway.
I've not read the patch...)

regards, tom lane

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Bruce Momjian 2015-03-31 21:06:49 Re: printing table in asciidoc with psql
Previous Message Kevin Grittner 2015-03-31 20:33:55 Re: Vacuuming big btree indexes without pages with deleted items