QtDecode doesn't provide sufficient result type information

[Veranika Liaukevich]

QtDecode class doesn't provide sufficient resulting type information in the checkType method.

Consequences: at least attributes selection and proper types casting don't work, a server crashes during the checkType process because of null pointer dereferencing.

This should return the first attribute

select decode($1).1

as it does for

select rgb.1 from rgb

This should return long values (or structures with attributes casted to long):

select (long) decode($1)

For example, for query "select (long) rgb from rgb" an array of "struct {long red, long green, long blue}" is returned.

[George Merticariu]

I have fixed the (long) conversion but I am not sure whether the values are actually converted, only that you won't get an error any longer. My thoughts:

From the type's point of view, decode works in the same way as the old inv_png, inv_tiff etc functions work, so it inherits the same limitations.

Rasdaman first builds the tree, then checks the types for each node and then starts the evaluation. The problem is that the datastream (i.e. $1 in decode($1)) needs to be evaluated in order to deduce the type. Since checkType happens before the evaluation, we don't know the type, so all the conversion results are set to char (same as in the old conversion functions).

This results in decode($1).1 not working: DOT expects the first input to be a struct-typed array and this check is done in the checkType() method, which happens before evaluate(). However, at this time we don't know anything about the type of $1 so we assume it is char.

Since this is the way rasdaman is built, I don't see any straight forward solution to this. We can add hacks for particular situations (e.g. if we consider all inputs structs .1 would work), but this only creates further problems.

Is it possible to add a pre-evaluation step, without knowledge of type information? Or, another thought, we could add an extra optional parameter to decode which is the mddBaseType.

In conclusion, decode is fully usable for inserting things into the db. If we want more features on top of it we need a solution to the type problem. But do we have use cases for that? (e.g. in mysql you wouldn't write SELECT (CREATE TABLE …))

[Dimitar Misev]

Replying to gmerticariu:

Is it possible to add a pre-evaluation step, without knowledge of type information? Or, another thought, we could add an extra optional parameter to decode which is the mddBaseType.

In comment:4:ticket:772 I have used such an extra parameter, but there it is necessary as the type cannot be deduced anyway and has to be supplied by the user.

As long as the segfault is fixed in the checkType this is fine, later on an exception will be thrown anyway if the type does not match within the convertor code itself.