Prev: Row-level Locks & SERIALIZABLE transactions, postgres vs. Oracle
Next: Stefan's bug (was: max_standby_delay consideredharmful)
From: Robert Haas on 19 May 2010 00:20 On Tue, May 18, 2010 at 6:26 PM, Ben Hockey <neonstalwart(a)gmail.com> wrote: > hi, > i mistakenly had posted this to pgsql-bugs already and got a response (see > below - edited). i'm posting here since afaik it is the way i should be > requesting new features. my suggestion is to add a DATESTYLE format to > match the format specified for date time strings in ecmascript 5. > the following is from the ecmascript 5 specification > at http://www.ecmascript.org/docs/tc39-2009-043.pdf page 168: > > 15.9.1.15 Date Time String Format > > ECMAScript defines a string interchange format for date-times based upon a > simplification of the ISO 8601 > > Extended Format. The format is as follows: YYYY-MM-DDTHH:mm:ss.sssZ > > 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. I don't object, if someone wants to write a patch. I guess the question is whether to keep adding named formats, or try to create a general mechanism to allow the user to specify an arbitrary format, as we do with to_char(). -- 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
From: Pavel Stehule on 19 May 2010 01:28 2010/5/19 Robert Haas <robertmhaas(a)gmail.com>: > On Tue, May 18, 2010 at 6:26 PM, Ben Hockey <neonstalwart(a)gmail.com> wrote: >> hi, >> i mistakenly had posted this to pgsql-bugs already and got a response (see >> below - edited).  i'm posting here since afaik it is the way i should be >> requesting new features.  my suggestion is to add a DATESTYLE format to >> match the format specified for date time strings in ecmascript 5. >> the following is from the ecmascript 5 specification >> at http://www.ecmascript.org/docs/tc39-2009-043.pdf page 168: >> >> 15.9.1.15 Date Time String Format >> >> ECMAScript defines a string interchange format for date-times based upon a >> simplification of the ISO 8601 >> >> Extended Format.  The format is as follows: YYYY-MM-DDTHH:mm:ss.sssZ >> >> 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. > > I don't object, if someone wants to write a patch.  I guess the > question is whether to keep adding named formats, or try to create a > general mechanism to allow the user to specify an arbitrary format, as > we do with to_char(). > I can write patch. I am against to general solution - It can be new way for SQL injection. Regards Pavel > -- > 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 > -- 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: Peter Eisentraut on 19 May 2010 02:19 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? -- 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: Pavel Stehule on 19 May 2010 02:25 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? JavaScript isn't special language, but JSON is wide used format for interoperability. And same is true for XML datestyle format. Regards Pavel > > > -- > Sent via pgsql-hackers mailing list (pgsql-hackers(a)postgresql.org) > To make changes to your subscription: > http://www.postgresql.org/mailpref/pgsql-hackers > -- 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: Mike Fowler on 19 May 2010 04:31
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 Pavel: Why do you believe a generic format function would lead to SQL injections attacks? > JavaScript isn't special language, but JSON is wide used format for > interoperability. And same is true for XML datestyle format. > > Regards > Pavel > I think that the postgres handling of those data types should handle the date encoding themselves. For example, a XMLELEMENT call that was passed a date would format the date string to the xs:date format (e.g. 2010-05-19) and when passed a timestamp format to xs:datetime (e.g. 2010-05-19T09:29:52+01:00). I would see the JSON handling as being no different. Thanks, -- Mike Fowler Registered Linux user: 379787 "I could be a genius if I just put my mind to it, and I, I could do anything, if only I could get 'round to it" -PULP 'Glory Days' -- Sent via pgsql-hackers mailing list (pgsql-hackers(a)postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers |