0
votes

I am using MonetDB v11.29.7 "Mar2018-SP1" on a Windows10 x64 bit operating system. When I perform a full outer join with two tables on respective varchar columns with lengths > 0 (type_digits > 0), the resultant column in the target table yields a varchar column with type_digits=0, although the column data seems to display the proper, non-null varchar records.

I am not sure how to interpret column information of type=varchar and type_digits=0. This state is causing issues in the subsequent handling/extraction of data via Python interfaces (UDFs), as the expected Python dtype for the data of this column is ambiguous for Python numpy conversion.

I have provided a simple example whereby I created two small tables (dummy4 and dummy5) with two columns each and then create a third table (dummy6) using a full outer join command.

For table dummy6 and column "key", I would have expected the type_digits=32 (as per the "key" columns in the two source tables dummy4 & dummy5). Additionally, how should I interpret type=varchar and type_digits=0 state? What would be the proper handling/expectation when accessing/allocating a Python/numpy array for extracting the "key" column of table "dummy6" (via Python UDFs) in this case?

create table dummy4(key varchar(32), val int);
insert into dummy4 values('AAAAAAAA',1);
insert into dummy4 values('BBBBBBBBB',2);

select * from dummy4;


+-----------+------+
| key       | val  |
+===========+======+
| AAAAAAAA  |    1 |
| BBBBBBBBB |    2 |
+-----------+------+

create table dummy5(key varchar(32), val int);
insert into dummy5 values('CCCCCCCC',3);
insert into dummy5 values('DDDDDDDD',4);

select * from dummy5;


+----------+------+
| key      | val  |
+==========+======+
| CCCCCCCC |    3 |
| DDDDDDDD |    4 |
+----------+------+

create table dummy6 as select key, dummy4.val as "val4", dummy5.val as "val5" from dummy4 full outer join dummy5 using (key);

select * from dummy6;


+-----------+------+------+
| key       | val4 | val5 |
+===========+======+======+
| AAAAAAAA  |    1 | null |
| BBBBBBBBB |    2 | null |
| CCCCCCCC  | null |    3 |
| DDDDDDDD  | null |    4 |
+-----------+------+------+

select t.name as "table_name", t.id as "table_id", c.id as "column_id", c.name as "column_name", c.type, c.type_digits from sys.tables t JOIN sys.columns c ON c.table_id = t.id where t.name = 'dummy4';


+------------+----------+-----------+-------------+---------+-------------+
| table_name | table_id | column_id | column_name | type    | type_digits |
+============+==========+===========+=============+=========+=============+
| dummy4     |    78445 |     78443 | key         | varchar |          32 |
| dummy4     |    78445 |     78444 | val         | int     |          32 |
+------------+----------+-----------+-------------+---------+-------------+

select t.name as "table_name", t.id as "table_id", c.id as "column_id", c.name as "column_name", c.type, c.type_digits from sys.tables t JOIN sys.columns c ON c.table_id = t.id where t.name = 'dummy5';


+------------+----------+-----------+-------------+---------+-------------+
| table_name | table_id | column_id | column_name | type    | type_digits |
+============+==========+===========+=============+=========+=============+
| dummy5     |    78449 |     78447 | key         | varchar |          32 |
| dummy5     |    78449 |     78448 | val         | int     |          32 |
+------------+----------+-----------+-------------+---------+-------------+

select t.name as "table_name", t.id as "table_id", c.id as "column_id", c.name as "column_name", c.type, c.type_digits from sys.tables t JOIN sys.columns c ON c.table_id = t.id where t.name = 'dummy6';


+------------+----------+-----------+-------------+---------+-------------+
| table_name | table_id | column_id | column_name | type    | type_digits |
+============+==========+===========+=============+=========+=============+
| dummy6     |    78457 |     78454 | key         | varchar |           0 |
| dummy6     |    78457 |     78455 | val4        | int     |          32 |
| dummy6     |    78457 |     78456 | val5        | int     |          32 |
+------------+----------+-----------+-------------+---------+-------------+
1

1 Answers

1
votes

In fact this was a MonetDB's bug and was fixed today. Th fix will be featured on the upcoming Nov2019 release.