Re: deparsing utility commands

From: Jim Nasby <Jim(dot)Nasby(at)BlueTreble(dot)com>
To: Alvaro Herrera <alvherre(at)2ndquadrant(dot)com>
Cc: "Shulgin, Oleksandr" <oleksandr(dot)shulgin(at)zalando(dot)de>, David Steele <david(at)pgmasters(dot)net>, Amit Kapila <amit(dot)kapila16(at)gmail(dot)com>, Pg Hackers <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: deparsing utility commands
Date: 2015-08-06 15:26:03
Message-ID: 55C37C8B.6000507@BlueTreble.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: 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

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Alvaro Herrera 2015-08-06 15:29:15 Re: Raising our compiler requirements for 9.6
Previous Message Andres Freund 2015-08-06 15:21:19 Re: Raising our compiler requirements for 9.6