Received: from golem.jpl.nasa.gov (root@hectic-1.jpl.nasa.gov [128.149.68.203]) by hub.org (8.8.8/8.7.5) with ESMTP id WAA12632; Thu, 16 Apr 1998 22:42:33 -0400 (EDT) Received: from alumni.caltech.edu (localhost [127.0.0.1]) by golem.jpl.nasa.gov (8.8.5/8.8.5) with ESMTP id CAA29727; Fri, 17 Apr 1998 02:45:03 GMT Sender: tgl@mythos.jpl.nasa.gov Message-ID: <3536C22F.A1F0978C@alumni.caltech.edu> Date: Fri, 17 Apr 1998 02:45:03 +0000 From: "Thomas G. Lockhart" Organization: Caltech/JPL X-Mailer: Mozilla 4.03 [en] (X11; I; Linux 2.0.30 i686) MIME-Version: 1.0 To: Byron Nikolaidis CC: Paul Lisewski , "pgsql-interfaces@postgreSQL.org" , Postgres Hackers List Subject: Re: [INTERFACES] Re: ODBC driver References: <5ABEF3A77B39D111970F0020AFA04D29AE1F@mailbox.techone.com.au> <35367D36.18531358@insightdist.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit > > {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