""kamiller42"" <kyle@...> wrote in message
news:a6qf1j+tj57@......

>
> > I didn't want to change that for compatibility but unfortunately, the

flaw

> > defeats several udfs. Any UDF returning cstring is affected. This is why

I

> > decided to return varchar in fbudf. And if your udf says that it returns

a

> > cstring(254), you will have 254 blanks minus the length of the

non-blanks

>
> The above paragraph makes it all clear now. Thank you! Any chance Firebird

might choose a different path with cstring() instead of one that returns
char instead of varchar? Or would this cause UDF's to be incompatible
between Firebird and Interbase?

It doesn't affect the UDF themselves. It only affects how the declaration is
done. If you have procedures where you assign the UDF result to a variable
of type cstring, you won't notice anything (maybe a small overhead).
If you have views and you recreate them, if one of the fields uses the UDF
that returns cstring, you have changed the view's field definition to
varchar.
If you have programs with static logic that expect char, maybe you'll have
problems.

It would be fine if the user's opinion is heared: what's better? Preserve
the current functionality of mapping UDFs that return cstring to varchar
instead of char? Or document the issue and let UDF creators to declare the
UDF return type as varchar and handle varchar intricacies directly inside
the UDF if they don't want to have problems with cstring? For example, fbudf
never uses cstring, for the current setting in the engine.

C.
--
Claudio Valderrama C. - http://www.cvalde.com - http://www.firebirdSql.org
Independent developer
Owner of the Interbase® WebRing