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
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 |