On Postgres, get_recordset_sql loads all the results into memory
(within the Postgres library, which doesn't count towards the PHP
memory limit, but does count towards making your server run out of
memory) as soon as the query completes.
This commit changes the code to use cursors, which in Postgres
allow the results to be returned in smaller chunks (by default
100,000 rows).
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.
