Bug or feature? Timestamp parsing

Поиск
Список
Период
Сортировка
От Josh Berkus
Тема Bug or feature? Timestamp parsing
Дата
Msg-id 4C101E57.1020805@agliodbs.com
обсуждение исходный текст
Ответы Re: Bug or feature? Timestamp parsing  (Tom Lane <tgl@sss.pgh.pa.us>)
Список pgsql-hackers
select 'NOW?'::TIMESTAMP;        timestamp
----------------------------2010-06-09 14:08:21.020259

postgres=# select ';;;infinity???#@$%$'::TIMESTAMP;timestamp
-----------infinity
(1 row)

It appears that the ts parser will ignore any punctuation surrounding
the special value calls.

In general, this isn't a potential problem.  However, it could cause
some confusion with careless value replacement by users.  Imagine a case
like this:

create or replace function epoch(integer) returns timestamp language sql
as 'SELECT ''epoch''::timestamp + $1 * interval ''1 second'';';

Then later you fail on your client quoting rules and do the following in
your app code:

UPDATE some_tableSET timestamp_field = 'epoch(150000)'
WHERE id = 501;

The above will result in 1970-01-01 00:00:00 UTC getting into the field,
not 1970-01-02 17:40:00 as the user intended, since the '(150000)' will
be ignored.  And given the lack of an error message, a lot of debugging
time.

On the other hand, it appears that our timestamps have had this bug
since at least 8.0, so it clearly isn't a widespread problem for most
users.  And likely some users have been "taking advantage" of letting
garbage into their timestamp casts, so there would be some application
breakage.

Thoughts?

--                                  -- Josh Berkus                                    PostgreSQL Experts Inc.
                        http://www.pgexperts.com
 


В списке pgsql-hackers по дате отправления:

Предыдущее
От: Simon Riggs
Дата:
Сообщение: Re: failover vs. read only queries
Следующее
От: Simon Riggs
Дата:
Сообщение: Re: How about closing some Open Items?