Re: BUG #3563: DATESTYLE feature suggestion - Mailing list pgsql-bugs

From Pavel Stehule
Subject Re: BUG #3563: DATESTYLE feature suggestion
Date
Msg-id AANLkTik4qvSy64-NzcGM7NDZOW-r8Y4Af9cS3_4nKDue@mail.gmail.com
Whole thread Raw
In response to Re: BUG #3563: DATESTYLE feature suggestion  (Ben Hockey <neonstalwart@gmail.com>)
List pgsql-bugs
Hello

2010/5/16 Ben Hockey <neonstalwart@gmail.com>:
> i apologize for bringing this up from over 2 years ago but i haven't been
> able to find how this issue was resolved.

it isn't bug, but request for new feature.

look on http://wiki.postgresql.org/wiki/Developer_FAQ

I have nothing against some new datestyles - xml, ecma5 and I am able
to add to pg when hackers will agree

Parametrised datestyle is little bit different. I know so it can be
used for SQL injection on Oracle. So I am not sure if it is a good
idea. But isn't problem create external project (maybe on pgFoundry)
for customized datatype.

Regards

Pavel Stehule

>
> 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. =C2=A0The 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. =C2=A0simplifying
> interoperability could be achieved by either providing a new format that
> matched this specific format or by allowing a way to specify a custom
> DATESTYLE format. =C2=A0being able to specify a custom DATESTYLE format w=
ould be
> preferred since it is the more flexible option.
>
> perhaps this is already possible but i just haven't managed to find it. =
=C2=A0any
> help appreciated.
>
> thanks,
>
> ben...
>
> On Aug 21, 2007, at 7:53 PM, Randolf Richardson wrote:
>
>>
>> The following bug has been logged online:
>>
>> Bug reference: =C2=A0 =C2=A0 =C2=A03563
>> Logged by: =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0Randolf Richardson
>> Email address: =C2=A0 =C2=A0 =C2=A0randolf+postgresql.org@inter-corporat=
e.com
>> PostgreSQL version: 8.2.4
>> Operating system: =C2=A0 NetBSD 4 (beta), NetBSD 3.1, NetWare 6.5
>> Description: =C2=A0 =C2=A0 =C2=A0 =C2=A0DATESTYLE feature suggestion
>> Details:
>>
>> After convincing clients and colleagues to switch from Oracle (and other=
s)
>> to PostgreSQL, an issue that comes up is the need to customize DATESTYLE.
>> Because this isn't possible, the developers who were against the move to
>> PostgreSQL make it political and recommended work-around solutions such =
as
>> using to_char() or implementing a view for each table that contain
>> TIMESTAMP[TZ]s is very difficult to argue with management because a lot =
of
>> time is required to implement these items.
>>
>> In a future version, to solve this problem, an additional DATESTYLE opti=
on
>> that uses the same rules as the to_char() function for date formatting
>> would
>> solve this problem. =C2=A0Here's an example:
>>
>> SET DATESTYLE =3D 'Custom YYYY-Mon-DD';
>>
>> This feature would not only resolve this particular political strife, but
>> would also solve many other problems, including simplifying coding for r=
aw
>> SQL output serving as reports (e.g., users still get confused about dates
>> like "2007-06-03," wondering if they refer to June 3rd, or March 6th).
>>
>> I'm hoping that this suggestion will be an easy one to implement.
>>
>> Thanks in advance.
>>
>> P.S.: =C2=A0I searched around for a "feature suggestions" page but could=
n't
>> find
>> it (if one exists, it should be linked to from the "Report a Bug" page).
>
>
> --
> Sent via pgsql-bugs mailing list (pgsql-bugs@postgresql.org)
> To make changes to your subscription:
> http://www.postgresql.org/mailpref/pgsql-bugs
>

pgsql-bugs by date:

Previous
From: Ben Hockey
Date:
Subject: Re: BUG #3563: DATESTYLE feature suggestion
Next
From: ""
Date:
Subject: BUG #5462: Can't intall onclick installer from EnterpriseDB