On Tue, Jul 25, 2017 at 7:43 PM, Tom Lane wrote:
> Rushabh Lathia writes:
> > On Mon, Jul 24, 2017 at 7:23 PM, Tom Lane wrote:
> >> Some looking around says that this *isn't* the only place that just
> >> blithely assumes that it will find an opfamily entry. But I agree
> >> that not checking
Rushabh Lathia writes:
> On Mon, Jul 24, 2017 at 7:23 PM, Tom Lane wrote:
>> Some looking around says that this *isn't* the only place that just
>> blithely assumes that it will find an opfamily entry. But I agree
>> that not checking for that isn't up to project standards.
> I go thorough the
On Mon, Jul 24, 2017 at 7:23 PM, Tom Lane wrote:
> Rushabh Lathia writes:
> > PFA patch, where added elog() to add the error message same as all other
> > places.
>
> Some looking around says that this *isn't* the only place that just
> blithely assumes that it will find an opfamily entry. But
Rushabh Lathia writes:
> PFA patch, where added elog() to add the error message same as all other
> places.
Some looking around says that this *isn't* the only place that just
blithely assumes that it will find an opfamily entry. But I agree
that not checking for that isn't up to project standar
Hi,
Consider the following test:
CREATE OR REPLACE FUNCTION dummy_binaryint4(a int4, b int4) RETURNS int4 AS
$$ BEGIN RETURN a; END; $$ LANGUAGE 'plpgsql' IMMUTABLE;
CREATE OPERATOR CLASS custom_opclass2 FOR TYPE int2 USING BTREE AS OPERATOR
1 = , FUNCTION 1 dummy_binaryint4(int4, int4);
t=# CR
