Issue Details (XML | Word | Printable)

Key: CORE-5315
Type: Improvement Improvement
Status: Open Open
Priority: Minor Minor
Assignee: Unassigned
Reporter: Geoff Worboys
Votes: 0
Watchers: 2
Operations

If you were logged in you would be able to see more operations.
Firebird Core

UDF by descriptor parameters sometimes get ttype_dynamic for character set

Created: 22/Jul/16 12:09 PM   Updated: 26/Jul/16 01:00 PM
Component/s: UDF
Affects Version/s: 2.5.6
Fix Version/s: None

Environment: Windows 10, Delphi 10.1, 32bit build

QA Status: No test


 Description  « Hide
Using "by descriptor" parameters a UDF can read the character set of a string input parameter by extracting the lower byte of paramdsc.dsc_sub_type. For example a UDF created to reflect the type and character set of its input parameter will work as expected in the following:

CREATE PROCEDURE TestReflectType (
    "Param1" VARCHAR(80) CHARACTER SET WIN1252
) RETURNS (
    "Result" VARCHAR(255)
) AS
BEGIN
  "Result" = ReflectType("Param1");
  SUSPEND;
END

The "Result" comes back reporting the character set was WIN1252 (id=53). However doing the following select from a client:

SELECT ReflectType('abcdef') FROM RDB$DATABASE

reports the character set as 127 - which is the ttype_dynamic value used internally to indicate the attachment character set. This value is not useful to a UDF (it doesn't know the attachment character set), and the ttype_dynamic should probably not escape the engine. The UDF parameter handling needs to be updated to replace ttype_dynamic with the attachment character set.


Note that the following EXECUTE BLOCK exhibits the same behaviour as the SELECT statement:

EXECUTE BLOCK (
    "Param1" VARCHAR(80) CHARACTER SET WIN1252 = ?
) RETURNS (
    "Result" VARCHAR(255)
) AS
BEGIN
  "Result" = ReflectType("Param1");
  SUSPEND;
END

But this may be a separate problem - regardless of the UDF parameter handling, "Param1" should have a character set as declared. If I can confirm it is a separate issue I'll raise another ticket and leave a reference to it here.

Edit: The EXECUTE BLOCK situation is a separate issue, see http://tracker.firebirdsql.org/browse/CORE-5316

 All   Comments   Change History   Subversion Commits      Sort Order: Ascending order - Click to sort in descending order
Geoff Worboys added a comment - 26/Jul/16 01:00 PM
Just confirming that this problem appears to be fixed in Firebird v3 (released version).

This:
    SELECT ReflectType('abcdef') FROM RDB$DATABASE

gives the UDF input type as having the client connection character set (rather than 127) - and that makes sense.

Note that this:
    SELECT ReflectType(:ParamName) FROM RDB$DATABASE

returns UDF input type as having the database default character set regardless of the connection character set. Definitely better than FB v2.

If you want to close this as "Won't Fix" that's okay with me. Now I know the problem exists I can work around it until I migrate to FB v3.