Re: [BUGS] Can't read oprcode from remote pg_operator
От | Tom Lane |
---|---|
Тема | Re: [BUGS] Can't read oprcode from remote pg_operator |
Дата | |
Msg-id | 19131.1504612659@sss.pgh.pa.us обсуждение исходный текст |
Ответ на | [BUGS] Can't read oprcode from remote pg_operator (Thom Brown <thom@linux.com>) |
Ответы |
Re: [BUGS] Can't read oprcode from remote pg_operator
|
Список | pgsql-bugs |
Thom Brown <thom@linux.com> writes: > It seems that, if you have a foreign table pointing to pg_operator in > another cluster, you cannot return the oprcode column for certain > rows. I'm getting this on 10 beta 3. I don't think that has anything to do with remoteness or not, nor which PG version you try. The regproc representation is inherently ambiguous, so even locally you will get: regression=# select oprcode::text::regproc from pg_operator; ERROR: more than one function named "pg_catalog.tsquery_phrase" Likewise for, eg, pg_aggregate.aggfnoid. > I have imported pg_operator using IMPORT FOREIGN SCHEMA, If that seemed like a widely useful thing to do, I might be more worried. But if you want to do this, I'd suggest making a view over pg_operator that casts the regproc columns to regprocedure, and then importing that. Even then, it will fail if the remote catalog contains references to any functions that don't exist locally. We've talked in the past about deprecating regproc/regoper and converting those columns to the fully qualified types; that would help the ambiguity part of your issue, though not the nonexistence part. But that's blocked on teaching genbki.pl to do the equivalent of regprocedurein and fill those columns with numeric OIDs in the BKI file. regards, tom lane -- Sent via pgsql-bugs mailing list (pgsql-bugs@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-bugs
В списке pgsql-bugs по дате отправления: