Date literal handling - JDBC assumes postgres and its forgiveness

Andrea Aime added a comment - 03/Jul/07 1:34 AM Each database should override the sql encoder and use its own functions to create dates of times. There is no standard in the sql language on how to build a date, time or timestamp object as far as I know. An alternative that would work for each database would be to use prepared statements, and let the driver do the encoding work. There is a catch thought, if prepared statements are not cached and reused, performance will go down (in some cases, such as DB2, quite significantly down).

Rob Atkinson added a comment - 03/Jul/07 1:52 AM Here is a rather simplistic patch, that just inserts the "date" keyword - this works for Oracle and Postgres, according to http://sqlzoo.net/howto/source/u.cgi/tip218780/i06dates.xml this will work for MySQL, but not DB2 or SQL-Server. As Andrea says. using prepared statements or getting the specialised data store to supply a binding would make more sense. My preference is for the former, since the geometryless data store I maintain allows plugging in the jdbc driver, so it doesnt necessarily know the underlying database type. A general solution would need to look into and prepare test cases for all sorts of date and timestamp formats. I guess we should be able to support any ISO date format supplied in the filter for a WFS call. Do the Cite tests cover any of this? They probably should. Rob

Andrea Aime added a comment - 23/May/10 5:47 AM Oracle JDBC-NG uses prepared statements and thus does not require escaping or formatting for dates, timestamps and the like