[Harbour] Extended field types in RDDs

[Ryszard Glab]

On 5 Sep 2007 at 1:10, Przemyslaw Czerpak wrote:

> OK - it's easy to do. Much more complicated is using NULL values in
> conditional expressions which control some statements, f.e. loops.
> I do not see any easy way to reproduce most commonly used DBMS logic
> without introducing undefined states. Seems that we will have to
> generate RT errors for conditional jumps executed for NULL value.
> It will still interact with -z optimization but seems to be much
> better then undefined results.

This is from MySQL documentation:
"In SQL, the NULL value is never true in comparison to any other 
value, even NULL. An expression that contains NULL always produces a 
NULL value unless otherwise indicated in the documentation for the 
operators and functions involved in the expression."

This meens that using NULL in comparison should be the same as 
logical FALSE:
Additionally:
IF( NULL, 1, 2) gives 2

> Interesting but IMHO it will more complicated then necessary.
> We will still have many different columns but in more dimensions.
> I'm interesting if we can define all possible non binary column
> attributes used in different DBMS to see how complicated will
> be addressing most of them.

  In SQL there are also ENUM and SET data types - I don't mean that 
we should support them in DBF tables but our RDD internals (and 
future SQLRDD) should be able to handle them. Thus DBCREATE structure 
should have some slot for such definitions - this is why I proposed 
an array.

Regards,
Ryszard