Re: [HACKERS] cache lookup failed error for partition key with custom opclass

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

Re: [HACKERS] cache lookup failed error for partition key with custom opclass

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

Re: [HACKERS] cache lookup failed error for partition key with custom opclass

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

Re: [HACKERS] cache lookup failed error for partition key with custom opclass

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

[HACKERS] cache lookup failed error for partition key with custom opclass

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