ecmascript 5 DATESTYLE
in [PgSql]
|
Prev: Row-level Locks & SERIALIZABLE transactions, postgres vs. Oracle
Next: Stefan's bug (was: max_standby_delay consideredharmful)
From: Ben Hockey on 20 May 2010 21:25 On May 19, 2010, at 4:31 AM, Mike Fowler wrote: > Pavel Stehule wrote: >> 2010/5/19 Peter Eisentraut <peter_e(a)gmx.net>: >> >>> On tis, 2010-05-18 at 18:26 -0400, Ben Hockey wrote: >>> >>>> ecmascript 5 is the most recent specification for JavaScript and i >>>> would think that having a DATESTYLE format to simplify >>>> interoperability with JavaScript applications would be highly >>>> desirable. >>>> >>> Note that we haven't got any other datestyles that are intended to >>> support interoperability with some language. It is usually the >>> job of >>> the client driver to convert PostgreSQL data (plural of datum) to >>> the >>> appropriate type and format for the client environment or >>> language. Is >>> there any reason why JavaScript would be different? >>> > > I wouldn't be keen to see dedicated language specific handling of > date/datetime formats. It would lead to an explosion of functions > with new languages needing adding as and when their users jumped up > and down on us. However a generic format could be very useful and > would give the opportunity for people who need a language specific > short cut the opportunity to do a CREATE FUNCTION wrapping the > generic one with a hard coded format specifier. > > Other platforms have generic support for this kind of task, for > example SQLServer: http://msdn.microsoft.com/en-us/library/ms187928.aspx > . I wouldn't recommend the SQLServer way, I think numeric format > specifiers are clumsy. Perhaps a mechanism like Java which is nicely > summarized here: http://java.sun.com/j2se/1.5.0/docs/api/java/text/SimpleDateFormat.html i think that http://unicode.org/reports/tr35/#Date_Format_Patterns is very similar to (maybe the same as) the java simple date format but the unicode link gives a more complete explanation of exactly how the formatters will be interpreted - ie y will represent the full representation of the year but yy will represent the 2 digit form of the year, etc.. just thought i'd share the reference since it provides a powerful way to generically specify date formats and is possibly something that many people might already be familiar with. thanks for looking into adding this feature. custom formats for parsing and formatting of dates would certainly be the better option if it can be done securely. thanks, ben.. -- Sent via pgsql-hackers mailing list (pgsql-hackers(a)postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
From: Robert Haas on 20 May 2010 23:34
On Thu, May 20, 2010 at 9:25 PM, Ben Hockey <neonstalwart(a)gmail.com> wrote: > thanks for looking into adding this feature. custom formats for parsing and > formatting of dates would certainly be the better option if it can be done > securely. Well, Pavel expressed a concern about SQL injection, but I can't see why that would be a problem. If having multiple date formats is insecure, then we are already insecure. If it's not, then I don't see why having user-definable formats would be any more insecure than having formats from a fixed list. In any case, I can't see the connection to SQL injection - it seems like the worst case scenario is that some client gets confused about what the date format is and some dates get misinterpreted. -- Robert Haas EnterpriseDB: http://www.enterprisedb.com The Enterprise Postgres Company -- Sent via pgsql-hackers mailing list (pgsql-hackers(a)postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers |