Re: deparsing utility commands
От | Jim Nasby |
---|---|
Тема | Re: deparsing utility commands |
Дата | |
Msg-id | 55C37C8B.6000507@BlueTreble.com обсуждение исходный текст |
Ответ на | Re: deparsing utility commands (Alvaro Herrera <alvherre@2ndquadrant.com>) |
Ответы |
Re: deparsing utility commands
|
Список | pgsql-hackers |
On 8/5/15 9:55 PM, Alvaro Herrera wrote: > Jim Nasby wrote: >> On 7/31/15 8:45 AM, Shulgin, Oleksandr wrote: > >>> STATEMENT: create view v1 as select * from t1 ; >>> ERROR: operator does not exist: pg_catalog.oid = pg_catalog.oid at >>> character 52 >>> HINT: No operator matches the given name and argument type(s). You >>> might need to add explicit type casts. >>> QUERY: SELECT * FROM pg_catalog.pg_rewrite WHERE ev_class = $1 AND >>> rulename = $2 >>> CONTEXT: PL/pgSQL function test_ddl_deparse() line 1 at FOR over SELECT >>> rows > >> I'm not sure what test_ddl_deparse is doing, is that where the oid = oid is >> coming from? >> >> It might be enlightening to replace = with OPERATOR(pg_catalog.=) and see if >> that works. > > That worked, thanks! Good, but why weren't operator resolution rules working correctly here to begin with? FWIW, my interest in this is largely due to the problems I've had with this in the variant type. In particular, using the same resolution rules for functions and operators. So I'm wondering if there's a bigger issue here. -- Jim Nasby, Data Architect, Blue Treble Consulting, Austin TX Data in Trouble? Get it in Treble! http://BlueTreble.com
В списке pgsql-hackers по дате отправления: