2B: 1C Solution Support

The 1C:Enterprise platform is supported starting from version 8.3.18.

Additional Data Types for Compatibility with Microsoft SQL Server

In QHB version 1.2.0 data types mchar and mvarchar were added, which are analogues of the char and varchar types, but have a number of behavioral features, repeating the behavior of the nchar and nvarchar types in Microsoft SQL Server.

Differences from the standard char and varchar types in QHB:

Case-insensitive comparison, in particular, if one of the arguments is mchar/mvarchar, and the second one is not (for case-sensitive comparison, special versions of comparison operators are provided: &<, &<=, &=, &>=, and &>).
The fixed-length mchar type is padded with spaces on the right, but for comparisons these spaces are ignored.
Data of mchar/mvarchar data type are stored in utf-16 encoding (for the user it doesn't matter).
ICU is used for comparison and conversion to upper/lower case, so the result does not depend on the operating system.
The function for getting a substring is substr(str, pos [, length]), not substring.

Differences from nchar and nvarchar behavior in Microsoft SQL Server:

mchar and mvarchar data types without specifying the length are treated as strings of undefined unlimited length (similar to nvarchar(max)); mchar of indefinite length is not padded with spaces on the right (but explicitly specified spaces are still stored).
The function for calculating the string length is length(string), not len, as in Microsoft SQL Server.

B-tree and hash indexes are supported for mchar and mvarchar data types.

fulleq — Additional Equality Operator for Compatibility with Microsoft SQL Server

For compatibility with Microsoft SQL Server, operator fulleq (full equality) == was added to QHB version 1.2.0.

The fulleq operator (==) differs from regular equality (=) in the fact that it returns true when comparing two NULL values (regular equality returns NULL according to ANSI SQL standard). This behavior is common in the Microsoft SQL DBMS family.

The == operator is defined for the following data types:

bool
bytea
char
mchar
varchar
mvarchar
name
int2
int4
int8
int2vector
text
oid
xid
cid
oidvector
float4
float8
macaddr
inet
cidr
date
time
timestamp
timestamptz
interval
timetz

Fast Temporary Table Emptying

In QHB the TRUNCATE operation is transactional: it can be rolled back. Because of this, it is more expensive than other DBMSs.

In version 1.2.0, the fasttruncate function was added, which empties the table faster and prevents the system catalog pg_class from bloating. At the moment it can only be applied to temporary tables, so truncation does not cause conflict with other users.

WARNING!
The fasttruncate function is non-transactional: when the transaction is rolled back, table truncation will not be cancelled!

Usage example:

SELECT fasttruncate ('pg_temp.tmp3')

Immediate Update of Individual Table Statistics

For tables that change a lot, such as temporary tables, standard statistics collection tools may be ineffective. In version QHB 1.2.0, it became possible to immediately update table statistics after it has been changed, the so-called online analyze.

Statistics collection is called after committing the transaction that modified the table, if certain conditions are met. This behavior is configured using the corresponding configuration parameters in the configuration file qhb.conf (see Section Immediate Statistics Update Configuration Parameters for details).

Support for Prompts to Planner that Allows to Disable or Enable Specific Indexes When Executing a Query

In QHB 1.2.0, configuration parameters were added to control the index usage (see Section Index Usage Management Configuration Parameters for details). With these, you can ask the planner to not use certain indexes. If you want a specific index to be used, these parameters are not enough, you should also use the enable_seqscan parameter and others.

These new settings are related to planner settings. As with other planner settings, the main use case is to change these parameters at the transaction level, before executing a specific query. It is technically possible to use parameters at the database or server level, but if you need to disable the index usage at the database level, it makes sense to consider dropping it.