Re: Bug in to_timestamp().

Sorry. I did not get last two mails from Amul. Don't know why. So I
reply to another mail.

> Documented as working case, but unfortunatly it does not :
>
> postgres=# SELECT to_timestamp('2000----JUN', 'YYYY MON');
> ERROR: invalid value "---" for "MON"
> DETAIL: The given value did not match any of the allowed values for this field.

Indeed! Fixed it. Now this query executes without error. Added this case
to tests.

> NODE_TYPE_CHAR assumption in else block seems incorrect. What if we have space after double quote? It will again have incorrect output without any error, see below:
>
> postgres=# SELECT to_timestamp('Year: 1976, Month: May, Day: 16',
> postgres(# '" Year:" YYYY, "Month:" FMMonth, "Day:" DD');
> to_timestamp
> ------------------------------
> 0006-05-16 00:00:00-07:52:58
> (1 row)
>
> I guess, we might need NODE_TYPE_SEPARATOR and NODE_TYPE_SPACE check as well?

Agree. Fixed and added to tests.

> Unnecessary hunk?
> We should not touch any code unless it necessary to implement proposed feature, otherwise it will add unnecessary diff to the patch and eventually extra burden to review the code. Similarly hunk in the patch @ line # 313 - 410, nothing to do with to_timestamp behaviour improvement, IIUC.
>
> If you think this changes need to be in, please submit separate cleanup-patch.

Fixed it. It was a typo.
About lines # 313 - 410. It is necessary to avoid bugs. I wrote aboud it
in
https://www.postgresql.org/message-id/b2a39359-3282-b402-f4a3-057aae500ee7%40postgrespro.ru
:

> - now DCH_cache_getnew() is called after parse_format(). Because now
> parse_format() can raise an error and in the next attempt
> DCH_cache_search() could return broken cache entry.

For example, you can test incorrect inputs for to_timestamp(). Try to
execute such query several times.

--
Artur Zakirov
Postgres Professional: http://www.postgrespro.com
Russian Postgres Company