PostgreSQL 9.1 allows hex formating for binary which is handled better
by pg_query_params().
Getting bytea isn't required on connection, it can be used as pg_field_type()
when binary needs to be checked.
- With the patch, 6 positions of scale accuracy are guaranteed
per individual casted value.
- Backed with unit tests, both for varchar and clob.
- Added 2 missing tests about uses of the method with params
and values.
Note: 6 was picked because looking to all databases implementation
postgres was found to be casting to real, aka, 6.
While we already were detecting @ normalise_value()
both BLOBs and CLOBs properly on insert and update
statements (by introspectind the column specs), when
a long TEXT is being passed as part of an arbitrary
SQL, or within the conditions... it was being bound
as VARCHAR, leading to problems if used in combination
with DBMS_LOB functions.
This patch just ensures that any TEXT > 4000 bytes not
detected by normalise_value() will be, always, bound as CLOB,
unconditionally.
Covered with tests both covering its use with DBMS_LOB (the
reported bug) and also in general raw statements.
MSSQL's substring() implementation is somehow silly/strict and unable to
perform implicit casts to integer both for the start and length parameters.
This hits Moodle badly because of another problems (MDL-23997) we decided
to cast to string all bound placeholders long ago.
So this commit just enforces the cast of the start and length parameters to
integer. And includes unit tests for using placeholders on all positions in
the sql_substr() method.
When insert_record is called and it doesn't find any columns
to insert data into, that is a dml_exception as you need at least
one column in the database to insert into it. This can happen
when you have created a zero column database table, or the table
does not exist.
Includes following fixes:
* support for MS SQL Server
* optional trimming of of oversized VARCHAR fields
* conversion to forms library
* full localisation
* other cleanup
Let's verify how all databases perform with a big
number of parameters (10000) using IN() SQL clauses.
Both using QM and NAMED parameters.
Ideally only Oracle fails, and only it will need fixing.
This is necessary because MySQL get_recordset_sql() stores the data in memory, unfortunately the alternative resultset iteration blocks concurrent access - that is why we need new method for export.
Marina Glancy