Full ∞ support for numeric context (#97)

Author: mkgrgis

README.md

@@ -39,18 +39,20 @@ Features
 - Support mixed SQLite [data affinity](https://www.sqlite.org/datatype3.html) input and filtering (`SELECT`/`WHERE` usage) for such data types as
 	- `timestamp`: `text` and `int`,
 	- `uuid`: `text`(32..39) and `blob`(16),
- 	- `bool`: `text`(1..5) and `int`.
+ 	- `bool`: `text`(1..5) and `int`,
+ 	- `double precision`, `float` and `numeric`: `real` values and special values with `text` affinity (`+Infinity` and `-Infinity`).
 - Support mixed SQLite [data affinity](https://www.sqlite.org/datatype3.html) output (`INSERT`/`UPDATE`) for such data types as
 	- `timestamp`: `text`(default) or `int`,
  	- `uuid`: `text`(36) or `blob`(16)(default).
+- Full support for `+Infinity` (means ∞) and `-Infinity` (means -∞) special values for IEEE 754-2008 numbers in `double precision`, `float` and `numeric` columns including such conditions as ` n < '+Infinity'` or ` m > '-Infinity'`.
 
 ### Pushdowning
 - `WHERE` clauses are pushdowned
 - Aggregate function are pushdowned
 - `ORDER BY` is pushdowned
 - Joins (left/right/inner/cross) are pushdowned
 - `CASE` expressions are pushdowned.
-- `LIMIT` and `OFFSET` are pushdowned (*when all tables queried are fdw)
+- `LIMIT` and `OFFSET` are pushdowned when all tables in the query are foreign tables belongs to the same PostgreSQL `FOREIGN SERVER` object.
 - Support `GROUP BY`, `HAVING` push-down.
 - `mod()` is pushdowned. In PostgreSQL this function gives [argument-dependend data type](https://www.postgresql.org/docs/current/functions-math.html), but result from SQLite always [have `real` affinity](https://www.sqlite.org/lang_mathfunc.html#mod).
 - `upper`, `lower` and other character case functions are **not** pushed down because they does not work with UNICODE character in SQLite.
@@ -129,7 +131,7 @@ Usage
 
 - **database** as *string*, **required**, no default
 
-  SQLite database path.
+  SQLite database file address.
 
 - **updatable** as *boolean*, optional, default *true*
 
@@ -557,6 +559,9 @@ Limitations
 - `TRUNCATE` in `sqlite_fdw` always delete data of both parent and child tables (no matter user inputs `TRUNCATE table CASCADE` or `TRUNCATE table RESTRICT`) if there are foreign-keys references with `ON DELETE CASCADE` clause.
 - `RETURNING` is not supported.
 
+### Mixed affinity support
+SQLite `text` affinity values which is different for SQLite unique checks can be equal for PostgreSQL because `sqlite_fdw` unifyes semantics of values, not storage form. For example `1`(integer), `Y`(text) and `tRuE`(text) SQLite values is different in SQLite but equal in PostgreSQL as `true` values of `boolean` column. This is also applicable for a data with `text` affinity in `uuid`, `timestamp`, `double precision`, `float` and `numeric` columns of foreign tables. **Please be carefully if you want to use mixed affinity column as PostgreSQL foreign table primary key**.
+
 ### Arrays
 - `sqlite_fdw` only supports `ARRAY` const, for example, `ANY (ARRAY[1, 2, 3])` or `ANY ('{1, 2 ,3}')`.
 - `sqlite_fdw` does not support `ARRAY` expression, for example, `ANY (ARRAY[c1, 1, c1+0])`.
@@ -566,7 +571,8 @@ Limitations
 - For `sum` function of SQLite, output of `sum(bigint)` is `integer` value. If input values are big, the overflow error may occurs on SQLite because it overflow within the range of signed 64bit. For PostgreSQL, it can calculate as over the precision of `bigint`, so overflow does not occur.
 - SQLite promises to preserve the 15 most significant digits of a floating point value. The big value which exceed 15 most significant digits may become different value after inserted.
 - SQLite does not support `numeric` type as PostgreSQL. Therefore, it does not allow to store numbers with too high precision and scale. Error out of range occurs.
-- SQLite does not support special values for IEEE 754-2008 numbers such as `NaN`, `+Infinity` and `-Infinity` in SQL expressions with numeric context. Also SQLite can not store this values with `real` [affinity](https://www.sqlite.org/datatype3.html). In opposite to SQLite, PostgreSQL can store special values in columns belongs to `real` datatype family such as `float` or `double precision` and use arithmetic comparation for this values. In oppose to PostgreSQL, SQLite stores `NaN`, `+Infinity` and `-Infinity` as a text values. Also conditions with special literals (such as ` n < '+Infinity'` or ` m > '-Infinity'` ) isn't numeric conditions in SQLite and gives unexpected result after pushdowning in oppose to internal PostgreSQL calculations. During `INSERT INTO ... SELECT` or in `WHERE` conditions `sqlite_fdw` uses given by PostgreSQL standard case sensitive literals **only** in follow forms: `NaN`, `-Infinity`, `Infinity`, not original strings from `WHERE` condition. *This can caused selecting issues*.
+- SQLite does not support `NaN` special value for IEEE 754-2008 numbers. Please use this special value very cerefully because there is no such conception in SQLite at all and `NaN` value treated in SQLite as `NULL`.
+- SQLite support `+Infinity` and `-Infinity` special values for IEEE 754-2008 numbers in SQL expressions with numeric context. This values can be readed with both `text` and `real` affiniy, but can be writed to SQLite only with `real` affinity (as signed out of range value `9e999`).
 
 ### Boolean values
 - `sqlite_fdw` boolean values support exists only for `bool` columns in foreign table. SQLite documentation recommends to store boolean as value with `integer` [affinity](https://www.sqlite.org/datatype3.html). `NULL` isn't converted, 1 converted to `true`, all other `NOT NULL` values converted to `false`. During `SELECT ... WHERE condition_column` condition converted only to `condition_column`.

deparse.c

@@ -5,7 +5,7 @@
  * Portions Copyright (c) 2018, TOSHIBA CORPORATION
  *
  * IDENTIFICATION
- *        deparse.c
+ *		deparse.c
  *
  *-------------------------------------------------------------------------
  */
@@ -2080,7 +2080,16 @@ sqlite_deparse_column_ref(StringInfo buf, int varno, int varattno, PlannerInfo *
 		 * Recommended form for normalisation is someone from 1<->1 with PostgreSQL
 		 * internal storage, hence usually this will not original text data.
 		 */
-		if (!dml_context && pg_atttyp == BOOLOID)
+		if (!dml_context && ( pg_atttyp == FLOAT8OID || pg_atttyp == FLOAT4OID || pg_atttyp == NUMERICOID) )
+		{
+			elog(DEBUG2, "floatN unification for \"%s\"", colname);
+			appendStringInfoString(buf, "sqlite_fdw_float(");
+			if (qualify_col)
+				ADD_REL_QUALIFIER(buf, varno);
+			appendStringInfoString(buf, sqlite_quote_identifier(colname, '`'));
+			appendStringInfoString(buf, ")");
+		}
+		else if (!dml_context && pg_atttyp == BOOLOID)
 		{
 			elog(DEBUG2, "boolean unification for \"%s\"", colname);
 			appendStringInfoString(buf, "sqlite_fdw_bool(");
@@ -2648,12 +2657,26 @@ sqlite_deparse_const(Const *node, deparse_expr_cxt *context, int showtype)
 		case INT4OID:
 		case INT8OID:
 		case OIDOID:
+			{
+				extval = OidOutputFunctionCall(typoutput, node->constvalue);
+				if (strspn(extval, "0123456789+-eE.") == strlen(extval))
+				{
+					if (extval[0] == '+' || extval[0] == '-')
+						appendStringInfo(buf, "(%s)", extval);
+					else
+						appendStringInfoString(buf, extval);
+				}
+				else
+					ereport(ERROR, (errcode(ERRCODE_FDW_INVALID_DATA_TYPE),
+							errmsg("Invalid input syntax. Invalid characters in number"),
+							errhint("Value: %s", extval)));
+			}
+			break;
 		case FLOAT4OID:
 		case FLOAT8OID:
 		case NUMERICOID:
 			{
 				extval = OidOutputFunctionCall(typoutput, node->constvalue);
-
 				/*
 				 * No need to quote unless it's a special value such as 'NaN' or 'Infinity'.
 				 * See comments in get_const_expr().
@@ -2665,8 +2688,28 @@ sqlite_deparse_const(Const *node, deparse_expr_cxt *context, int showtype)
 					else
 						appendStringInfoString(buf, extval);
 				}
+				else if (strcasecmp(extval, "Inf") == 0 ||
+						 strcasecmp(extval, "Infinity") == 0 ||
+						 strcasecmp(extval + 1, "Inf") == 0 ||
+						 strcasecmp(extval + 1, "Infinity") == 0)
+				{
+					bool is_negative_or_positive = false;
+					if (extval[0] == '-' || extval[0] == '+')
+						is_negative_or_positive = true;
+
+					if (is_negative_or_positive)
+						appendStringInfo(buf, "(%c", extval[0]);
+
+					appendStringInfo(buf, "9e999");
+
+					if (is_negative_or_positive)
+						appendStringInfo(buf, ")");
+				}
 				else
+				{
+					/* NaN and other */
 					appendStringInfo(buf, "\'%s\'", extval);
+				}
 			}
 			break;
 		case BITOID:
@@ -2677,7 +2720,7 @@ sqlite_deparse_const(Const *node, deparse_expr_cxt *context, int showtype)
 				{
 					ereport(ERROR, (errcode(ERRCODE_FDW_INVALID_DATA_TYPE),
 							errmsg("SQLite FDW dosens't support very long bit/varbit data"),
-							errhint("bit length %ld, maxmum %ld", strlen(extval), SQLITE_FDW_BIT_DATATYPE_BUF_SIZE - 1)));
+							errhint("bit length %ld, maximum %ld", strlen(extval), SQLITE_FDW_BIT_DATATYPE_BUF_SIZE - 1)));
 				}
 				appendStringInfo(buf, "%lld", binstr2int64(extval));
 			}
@@ -2726,12 +2769,8 @@ sqlite_deparse_const(Const *node, deparse_expr_cxt *context, int showtype)
 			}
 			break;
 		case UUIDOID:
-			/* always deparse to BLOB because this is internal PostgreSQL storage
-			 * the string for BYTEA always seems to be in the format "\\x##"
-			 * where # is a hex digit, Even if the value passed in is
-			 * 'hi'::bytea we will receive "\x6869". Making this assumption
-			 * allows us to quickly convert postgres escaped strings to sqlite
-			 * ones for comparison
+			/* always deparse to BLOB, in case of UPDATE with text affinity
+			 * transformation function will be added
 			 */
  			{
 				int i = 0;
@@ -3031,7 +3070,13 @@ sqlite_deparse_scalar_array_op_expr(ScalarArrayOpExpr *node, deparse_expr_cxt *c
 					switch (c->consttype)
 					{
 						case INT4ARRAYOID:
+						case INT8ARRAYOID:
+						case INT2ARRAYOID:
+						case BOOLARRAYOID:
 						case OIDARRAYOID:
+						case NUMERICARRAYOID:
+						case FLOAT4ARRAYOID:
+						case FLOAT8ARRAYOID:
 							isstr = false;
 							break;
 						default: