Suggested mappings would be a big help.
Thanks,
Byron
Thomas G. Lockhart wrote:
> > > {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