Allow for different SQL dialects in test cases

[imanuelcostigan]

A quick note for the time being, which I will hopefully have time to expand a bit later.

The test_result() suite runs a number of data type tests which I think rely on data type names which may not be coextensive across DBMS. For example, the data_logical() tries to cast the integer 1 to a boolean value. However, SQL Server for example, does not have a BOOLEAN type; rather it has a BIT type.

Is there some way that we can map type names across different DBMS to make these tests more backend agnostic?

[imanuelcostigan]

Consistently calling dbDataType on the expected value per data_raw tests looks like it will work.

[imanuelcostigan]

Similar type of problem: SQL Server does not define a DATE() function. As a result, the data_date test fails with the message:

Unable to retrieve result set for 
SELECT date('2015-01-01') as a, date('2015-02-02') as b, 
date('2015-03-03') as c, date('2015-04-04') as d, date('2015-05-05') as e, 
date('2015-06-06') as f, date('2015-07-07') as g, date('2015-08-08') as h, 
date('2015-09-09') as i, date('2015-10-10') as j, date('2015-11-11') as k, 
date('2015-12-12') as l, current_date as m: 
'date' is not a recognized built-in function name.

The equivalent in SQL Server is DATENAME() I think

[imanuelcostigan]

Another one: data_time where SQL generated is SELECT time '00:00:00' as a, time '12:34:56' as b, current_time as c. This fails to parse in SQL Server. Instead something like this would be needed: SELECT CAST('00:00:00' as time(7)) as a...

Similarly, SELECT time('00:00:00') as a, time('12:34:56') as b, current_time as c: 'time' is not a recognized built-in function name.

[imanuelcostigan]

Also related #77

[krlmlr]

Tweaks for creating date, time and timestamp literals will be available very soon. A similar approach can be used for #77.