irstv/orbisgis — pull request #12 by gourlaysama (2012-06-28 14:45:18+00:00)
Title: Better support for the NULL keyword

This is technically a minor change but we have to be extra careful when changing the type system. Three things changed:
* There is now a clear separation between the expected type of a column (an instance of ```org.gdms.data.types.Type```), and the actual type of a value (a typeCode, i.e. one of the ```int``` constants defined in the ```Type``` class.

WARNING! This breaks the public API of functions:

```java
Type getType(Type[] argsTypes);
// becomes
int getType(int[] typeCodes);
```

All functions in master are updated to the new API, others (plugins,...) will need to be updated as well.

* **This disallows columns of NULL type**. NULL is still an actual data type (i.e. it has a typeCode) and is still a singleton type that sits at the bottom of the type hierarchy (everything can be NULL), but **no instance of ```Type``` can be created from a NULL type code**, which means that NULL is no longer a column type.

* This clarifies the overloading resolution and inference rules for NULL values (which used to be implicit):
> If a ```NULL``` identifier is directly present in an SQL expression, its static type is determined as follow:
> * if it is an argument to a function, overloading resolution on non-NULL types is performed and if several function signatures are remaining, the first one (in declaration order) is chosen.
> * if it is used by a numeric operator, it has the type that causes the result of the operator call to have the smallest type it can have (for example, ```(1 :: float) * NULL``` is of ```float``` type, not ```double```.
> * in any other case, the NULL value keeps its NULL type.
> * if the NULL typed expression is an argument to an operator that has a return type which does not depend on it being given something of NULL type, then nothing more happens (for example, boolean operators always have boolean return type).
> * if the NULL typed expression is a the root of a filtering expression (any SQL expression that sould return a boolean by design, like ```WHERE```, ```HAVING```, join predicates, etc.), it is taken as an UNKNOWN boolean value.
> * if the NULL typed expression is a the root of a SELECT clause, an exception is thrown because it would result in a table with NULL column type, which is not possible.

The bottom line is that all these queries are valid:
```sql
SELECT abs(NULL); // type byte (first one declared in abs)
SELECT * FROM myTable WHERE NULL; // result type null
//used as a boolean, nothing is selected
SELECT 1 + NULL; // result type int
SELECT (1 :: float) ^ NULL; // result type float
```
Whereas this one is obviously invalid:
```sql
SELECT NULL;
```

Does this make sense to everyone?

/cc @ebocher, @gpetit, @agueganno