You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
After add new like-intrenal index access method ( as like-btree, like-hash..), there are several problems as below.
If you create a new op class by new access method and you create a table in partition key that include new defined op class, you will get a error. For example: CREATE FUNCTION my_int4_sort(int4,int4) RETURNS int LANGUAGE sql AS $$ SELECT CASE WHEN $1 = $2 THEN 0 WHEN $1 > $2 THEN 1 ELSE -1 END; $$; CREATE OPERATOR CLASS test_int4_ops FOR TYPE int4 USING usbtree AS OPERATOR 1 < (int4,int4), OPERATOR 2 <= (int4,int4), OPERATOR 3 = (int4,int4), OPERATOR 4 >= (int4,int4), OPERATOR 5 > (int4,int4), FUNCTION 1 my_int4_sort(int4,int4); CREATE TABLE partkey_t (a int4) PARTITION BY RANGE (a test_int4_ops);
Because cbdb core will find a op class by BTREE_AM_OID when using partition key and not identify new defined opclass.
When use onconflict clause , it still has the problem. For example: create table insertconflicttest(key int4, fruit text); create unique index op_index_key on insertconflicttest(key, fruit text_pattern_ops); insert into insertconflicttest values(0, 'Crowberry') on conflict (key, fruit text_pattern_ops) do nothing;
In onconflict clause, it will find text_pattern_ops opclass by BTREE_AM_OID and compare result and existing index info. So it report a error that unmatched.
What you think should happen instead
Core idea is add a new hook that catch correct opclasses. For example, you can get all opclasses of BTREE_AM_OID firstly, if you can find target , you can find other opclasses in like-btree index access method(maybe user-defined).
Cloudberry Database version
Any version
What happened
After add new like-intrenal index access method ( as like-btree, like-hash..), there are several problems as below.
If you create a new op class by new access method and you create a table in partition key that include new defined op class, you will get a error. For example:
CREATE FUNCTION my_int4_sort(int4,int4) RETURNS int LANGUAGE sql
AS $$ SELECT CASE WHEN $1 = $2 THEN 0 WHEN $1 > $2 THEN 1 ELSE -1 END; $$;
CREATE OPERATOR CLASS test_int4_ops FOR TYPE int4 USING usbtree AS
OPERATOR 1 < (int4,int4), OPERATOR 2 <= (int4,int4),
OPERATOR 3 = (int4,int4), OPERATOR 4 >= (int4,int4),
OPERATOR 5 > (int4,int4), FUNCTION 1 my_int4_sort(int4,int4);
CREATE TABLE partkey_t (a int4) PARTITION BY RANGE (a test_int4_ops);
Because cbdb core will find a op class by BTREE_AM_OID when using partition key and not identify new defined opclass.
When use onconflict clause , it still has the problem. For example:
create table insertconflicttest(key int4, fruit text);
create unique index op_index_key on insertconflicttest(key, fruit text_pattern_ops);
insert into insertconflicttest values(0, 'Crowberry') on conflict (key, fruit text_pattern_ops) do nothing;
In onconflict clause, it will find text_pattern_ops opclass by BTREE_AM_OID and compare result and existing index info. So it report a error that unmatched.
What you think should happen instead
Core idea is add a new hook that catch correct opclasses. For example, you can get all opclasses of BTREE_AM_OID firstly, if you can find target , you can find other opclasses in like-btree index access method(maybe user-defined).
How to reproduce
Please refer exmaples as above.
Operating System
Linux
Anything else
No response
Are you willing to submit PR?
Code of Conduct
The text was updated successfully, but these errors were encountered: