Getting error while trying to insert date with the format 'dd-month-yyyy' , 'day-mm-yyyy' etc..

Rushabh Lathia
2009-06-10T08:20:05+00:00

Getting error while trying to insert date with the format 'dd-month-yyyy' ,
'day-mm-yyyy' (format which add the space in between the date ) etc..

Testcase:
========
postgres=# d t
     Table "public.t"
 Column | Type | Modifiers


Debugged the issue and found that error coming from date-in() ->
DecodeDateTime(). Problem here is whenever any space comes in the date
ParseDateTime() unable to break string into tokens based on a date/time
context.



Re: Getting error while trying to insert date with the format 'dd-month-yyyy' , 'day-mm-yyyy' etc.. by Tom Lane on 2009-06-10T14:11:27+00:00
Rushabh Lathia <rushabh.lathia@gmail.com> writes:
> Getting error while trying to insert date with the format 'dd-month-yyyy' ,
> 'day-mm-yyyy' (format which add the space in between the date ) etc..

1. Why are you bothering with the completely pointless to-char call at all?

2. It is not a bug that to-char is capable of emitting formats that
won't be read by the standard datetime input converter.  If you insist
on making a useless conversion to char and back, it's on your head to
choose a format setting that will work.

			regards, tom lane


Re: Getting error while trying to insert date with the format 'dd-month-yyyy' , 'day-mm-yyyy' etc.. by Peter Eisentraut on 2009-06-10T18:33:28+00:00
On Wednesday 10 June 2009 17:10:42 Tom Lane wrote:
> Rushabh Lathia <rushabh.lathia@gmail.com> writes:
> > Getting error while trying to insert date with the format 'dd-month-yyyy'
> > , 'day-mm-yyyy' (format which add the space in between the date ) etc..
>
> 1. Why are you bothering with the completely pointless to-char call at all?

Random guess for entertainment: Oracle applications do this sort of thing all 
the time.

> 2. It is not a bug that to-char is capable of emitting formats that
> won't be read by the standard datetime input converter.  If you insist
> on making a useless conversion to char and back, it's on your head to
> choose a format setting that will work.

Of course they then also use to-date all the time.


Re: Getting error while trying to insert date with the format 'dd-month-yyyy' , 'day-mm-yyyy' etc.. by Rushabh Lathia on 2009-06-11T04:14:34+00:00
On Thu, Jun 11, 2009 at 12:02 AM, Peter Eisentraut <peter-e@gmx.net> wrote:

> On Wednesday 10 June 2009 17:10:42 Tom Lane wrote:
> > Rushabh Lathia <rushabh.lathia@gmail.com> writes:
> > > Getting error while trying to insert date with the format
> 'dd-month-yyyy'
> > > , 'day-mm-yyyy' (format which add the space in between the date ) etc..
> >
> > 1. Why are you bothering with the completely pointless to-char call at
> all?
>
> Random guess for entertainment: Oracle applications do this sort of thing
> all
> the time.


I thought when we are providing the different format into to-char for
datetime then  standard datetime input converters should also have the
capability to read that format.


>
> > 2. It is not a bug that to-char is capable of emitting formats that
> > won't be read by the standard datetime input converter.  If you insist
> > on making a useless conversion to char and back, it's on your head to
> > choose a format setting that will work.
>
> Of course they then also use to-date all the time.


Yes, its we can always use to-date.


Re: Getting error while trying to insert date with the format 'dd-month-yyyy' , 'day-mm-yyyy' etc.. by Tom Lane on 2009-06-11T04:35:00+00:00
Rushabh Lathia <rushabh.lathia@gmail.com> writes:
> I thought when we are providing the different format into to-char for
> datetime then  standard datetime input converters should also have the
> capability to read that format.

to-char is designed to support a near-infinite number of output formats,
including many that are necessarily ambiguous.  There is no intention
whatsoever that they all be readable by the input converters.

It might or might not be useful to adjust the input converters to read
the specific format you chose.  But "to-char produced it" is simply not
an interesting argument in favor of that.

			regards, tom lane

Loading


$ This page is proudly powered by www.pubbs.net, you can see more at pgsql archive | Partners: Global Manufacturers