It is now safe to cache a reference to a cache and expect consistent results.
Changing identifiers altered cache results where a reference was
held to the cache. Identifiers have been set to be cached with
identifiers included so the caches are separate.
As a consequence of this it was identified that invalidation events
and identifiers don't easily work together as an event can't determine
which identifiers should be used for cache invalidation. So invalidation
events have been made incompatible with identifiers being set. No core
code used this combination as it's not possible to understand any expected
behaviour.
Event invalidation for application and session caches was centralised to the same
location. The only difference was the name of the lastinvalidation variable. This
improves support and consistency of invalidation code.
pgbouncer doesn't accept the PostgreSQL options command as it can't
process it. If you are using pgBouncer you need to make sure your
database is configured to set client encoding and standard_conforming_strings
correctly on each connection. pgBouncer can do this, as can ALTER
commands.
Also using sockets without a filename did not allow different ports to work.
This is because you either specify a filename which includes a port or
you just specify a port and libpq works out the correct socket location.
This commit just:
- Moves the null => '' to better place, restricting it to PHP >= 7.0
(bug https://bugs.php.net/bug.php?id=72524)
- Adds a couple of notes here and there.
- Changes some small details to keep the file using the same coding.
These are our bugs actually - the oci docs are very clear that bound
params should be in-scope when oci_execute is called - and due to pass by value etc,
this was not true for our driver.
There is another bug that needed fixing - OCI barfs if null values are bound - this
can be avoided by setting them to '' which oci treats as null.
And finally - all our lob/clob/blob hacks were also binding to local "out-of-scope" vars.
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.
Without it, transactions are executed in standard READ_COMMITED
mode, without snapshoting/row versioning, leading to update
conflicts under high concurrency.
Without it, transactions are executed in standard READ_COMMITED
mode, without snapshoting/row versioning, leading to update conflicts
under high concurrency.
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.
