[mariuz]

Fixes #9222

Summary

In Firebird 2.5 through 5.0, DsqlRequest::parseMetadata reset ttype_dynamic (CS_dynamic) to ttype_none (CS_NONE) for text items in DSQL message metadata so that clients encoding SQL_TEXT/SQL_VARYING using plain blr_text/blr_varying (which MetadataFromBlr maps to CS_dynamic) would not fail with string truncation or validation errors on NONE/OCTETS columns over multi-byte connection charsets.

When parseMetadata and mapInOut were replaced by DsqlDmlRequest::metadataToFormat in #8145 (11d5d59), that reset was dropped, causing wire-protocol clients that send plain blr_text/blr_varying to fail on Firebird 6.0 with:

• string right truncation (expected length N/4, actual M) when fetching CHARACTER SET NONE / OCTETS / ASCII columns (including system columns like RDB$RELATION_CONSTRAINTS.RDB$CONSTRAINT_TYPE) over UTF8.
• Malformed string when fetching or binding OCTETS or non-UTF8 NONE data over UTF8.

This PR restores the ttype_dynamic → ttype_none reset in DsqlDmlRequest::metadataToFormat.

[aafemt]

I would move this code a couple lines up in order not to call setTextType twice. Besides, reset text type not to NONE unconditionally but to the text type from oldFormat (which should be the real charset of the column).

[mariuz]

@aafemt Updated in d5b7692 to resolve textType == ttype_dynamic to oldFormat->fmt_desc[param->par_parameter].getTextType() before calling desc.setTextType(textType).

[aafemt]

I wonder if my suggestion did break the case when non-text field is requested as text. May be it worth check that old format is also text and otherwise fallback to ttype_none...