Re: 9.5 BLOCKER: regrole and regnamespace and quotes

From: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
To: Jim Nasby <Jim(dot)Nasby(at)bluetreble(dot)com>
Cc: Pg Hackers <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: 9.5 BLOCKER: regrole and regnamespace and quotes
Date: 2016-01-04 03:43:09
Message-ID: 27777.1451878989@sss.pgh.pa.us
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

Jim Nasby <Jim(dot)Nasby(at)bluetreble(dot)com> writes:
> On 1/3/16 9:23 PM, Tom Lane wrote:
>> I'm inclined to leave to_regrole and to_regnamespace alone, though, since
>> they have no numeric-OID path, and they will provide an "out" for anyone
>> who wants to handle nonquoted names. (Though at least in HEAD we ought to
>> fix them to take type text as input. Using cstring for ordinary functions
>> is just sloppy.)

> None of the other to_reg* casts do that though, so this would be
> inconsistent.

Good point. Also, anybody who really does want it like that can still
fall back to the traditional sub-SELECT-from-the-catalog approach.

> Another potential problem for regnamespace is that it doesn't allow an
> entry for the catalog. I'm not sure what the spec says about that, but
> every other function allows dbname.schema.blah (dbname == catalog).

Meh, these types conform to no spec, so we can make them do what we
like. I see about zero reason to allow a catalog name, it would mostly
just confuse people.

> I started working on a fix, but it's currently blowing up in bootstrap
> and I haven't been able to figure out why yet:
> running bootstrap script ... FATAL: improper qualified name (too many
> dotted names): oid_ops

Recommendation: don't muck with DeconstructQualifiedName. That is called
in too many places and we are *not* touching any such API twenty-four
hours before release wrap.

There's no real advantage to that anyway, compared with just doing
stringToQualifiedNameList and then complaining if its list_length isn't 1.

regards, tom lane

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Peter Geoghegan 2016-01-04 03:43:48 Re: Broken lock management in policy.c.
Previous Message Alvaro Herrera 2016-01-04 03:39:26 Re: row_security GUC does not behave as documented