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