Lists: | pgsql-admin |
---|
From: | Technical Doubts <online(dot)technicaldoubts(at)gmail(dot)com> |
---|---|
To: | pgsql-admin(at)postgresql(dot)org |
Subject: | to_timestamp error between postgres version 8.3 and 9.2 |
Date: | 2013-08-31 05:19:12 |
Message-ID: | CAJyuQsEP6af-MzxS=utG_4AN9ziHyDEOLSmecTiRt-fD7i+jCg@mail.gmail.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Lists: | pgsql-admin |
Dear Team,
I have a table with name registers_info with below columns
regid character varying,
transid bigint,
regdate timestamp without time zone,
canceldate timestamp without time zone
insert into registers_info (regid,transid,regdate,canceldate) values
('reg1',1,to_timestamp('2013-07-24','yyyy-MM-dd
hh24:mi:ss')::TIMESTAMP,to_timestamp('null','yyyy-MM-dd
hh24:mi:ss')::TIMESTAMP);
The above query works fine in Postgres 8.3 version.
But the same query when executed in postgres 9.2 its throwing below error
ERROR: invalid value "null" for "yyyy"
Detail: Value must be an integer.
From application, this cancel date might have values or it may come as null.
Kindly suggest. Thanks in advance.
--
John
From: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
---|---|
To: | Technical Doubts <online(dot)technicaldoubts(at)gmail(dot)com> |
Cc: | pgsql-admin(at)postgresql(dot)org |
Subject: | Re: to_timestamp error between postgres version 8.3 and 9.2 |
Date: | 2013-08-31 05:47:00 |
Message-ID: | 14883.1377928020@sss.pgh.pa.us |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Lists: | pgsql-admin |
Technical Doubts <online(dot)technicaldoubts(at)gmail(dot)com> writes:
> insert into registers_info (regid,transid,regdate,canceldate) values
> ('reg1',1,to_timestamp('2013-07-24','yyyy-MM-dd
> hh24:mi:ss')::TIMESTAMP,to_timestamp('null','yyyy-MM-dd
> hh24:mi:ss')::TIMESTAMP);
> The above query works fine in Postgres 8.3 version.
> But the same query when executed in postgres 9.2 its throwing below error
> ERROR: invalid value "null" for "yyyy"
> Detail: Value must be an integer.
Yup. It was never intended that 'null' would be valid input for
to_timestamp, and that's thrown an error since 8.4. See thread here:
http://www.postgresql.org/message-id/37ed240d0808291839t21e19956mdfbdc80aeb1b3c19@mail.gmail.com
A quick test says that 8.3 and older did this:
regression=# select to_timestamp('null','yyyy-MM-dd hh24:mi:ss');
to_timestamp
---------------------------
0001-01-01 00:00:00-05 BC
(1 row)
which can hardly be considered a sane interpretation of 'null', even
if we wanted to accept that input.
regards, tom lane
From: | françois Figarola <francois(dot)figarola(at)laposte(dot)net> |
---|---|
To: | pgsql-admin(at)postgresql(dot)org |
Subject: | Re: to_timestamp error between postgres version 8.3 and 9.2 |
Date: | 2013-08-31 05:52:24 |
Message-ID: | 52218498.6020302@laposte.net |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Lists: | pgsql-admin |
I think it's only a syntax problem :
to_timestamp('null','yyyy-MM-ddhh24:mi:ss')::TIMESTAMP
In this form your 'null' parameter is a text which dont match for your
definition, so the function is waiting for an integer representing the
year and fails.
But if you write :
to_timestamp(null,'yyyy-MM-ddhh24:mi:ss')::TIMESTAMP
the function return a NULL value.
Hope it helps.
Le 31/08/2013 07:19, Technical Doubts a écrit :
>
> Dear Team,
>
> I have a table with name registers_info with below columns
>
> regid character varying,
> transid bigint,
> regdate timestamp without time zone,
> canceldate timestamp without time zone
>
>
> insert into registers_info (regid,transid,regdate,canceldate) values
> ('reg1',1,to_timestamp('2013-07-24','yyyy-MM-dd
> hh24:mi:ss')::TIMESTAMP,to_timestamp('null','yyyy-MM-dd
> hh24:mi:ss')::TIMESTAMP);
>
> The above query works fine in Postgres 8.3 version.
>
> But the same query when executed in postgres 9.2 its throwing below error
>
> ERROR: invalid value "null" for "yyyy"
> Detail: Value must be an integer.
>
> From application, this cancel date might have values or it may come as null.
>
> Kindly suggest. Thanks in advance.
>
>
> --
> John