> > {fn UCase(...) ODBC function is not supported. Are you planning
> > to support ODBC functions??
> There are a ton of scalar functions that would need to be supported:
> Strings: ascii, char, concat, difference, insert, lcase, left,
> length, locate, ltrim, repeat, replace, right, rtrim, soundex, space,
> substring, ucase
>
> Numerics: abs, acos, asin, atan, atan2, ceiling, cos, cot, degrees,
> exp, floor, log, log10, mod, pi, power, radians, rand, round, sign,
> sin, sqrt, tan, truncate
>
> Dates: curdate, curtime, dayname, dayofmonth, dayofweek, dayofyear,
> hour, minute, month, monthname, now, quarter, second, timestampadd,
> timestampdiff, week, year
>
> System Functions: database, ifnull, user
>
> And of course, the granddaddy of all functions, CONVERT().
>
> Now, some of the string functions like '{fn ucase()}' could fairly
> easily be mapped to the Postgres "Upper" function. But what about all
> the others?
> Should they be implemented in the driver or in the backend? Or do we
> just do the easy ones?
Let's do both. Some already map to existing functions, which mean you
get to do this in your driver I suppose. Others, like many of the math
routines, should/could be in the backend.
How do you want to organize attacking these? I can help now with
suggesting mappings for existing functions (e.g. date_part('dow',
datetime) gives you "dayofweek") and can help with new functions in a
month or two. Or, perhaps others can help with that more quickly...
- Tom
