Обсуждение: Confusing information in sections 8.5 and 9.9 (date and time types, functions and operators)

The following documentation comment has been logged on the website:

Page: https://www.postgresql.org/docs/11/datatype-datetime.html
Description:

Both sections mention syntax TIMESTAMP '2019-01-20 08:00' as valid for input
of timestamp data. This seems to work fine in psql, however, this syntax
causes Syntax error when used in library access to the server (in my case it
is via pg module in NodeJS). After spending half a day looking for error, I
learned from the javascript module developer that the mentioned syntax
cannot be used for programmatic access. Instead, he recommended to use cast
operator form '2019-01-20 08:00'::timestamp.
I tested his suggestion (it works, of course) and was looking for some
mention or confirmation in the documentation, but found nothing. I think
this is a serious issue, especially because the alternative possibility of
using ::timestamp is not even mentioned in chapters 8.5 or 9.9. If someone
(like me) looks for specific information how to handle date & time literals,
they will inevitably fall into the same trap.
Since the experienced Syntax error is contrary to what one would expect
after reading the SQL language manual, could you please at least add some
hyperlink in both sections 8.5 and 9.9 to attract reader's attention to this
specific behavior of the database server? Thank you.

On Tue, Apr  9, 2019 at 02:50:14PM +0000, PG Doc comments form wrote:
> The following documentation comment has been logged on the website:
> 
> Page: https://www.postgresql.org/docs/11/datatype-datetime.html
> Description:
> 
> Both sections mention syntax TIMESTAMP '2019-01-20 08:00' as valid for input
> of timestamp data. This seems to work fine in psql, however, this syntax
> causes Syntax error when used in library access to the server (in my case it
> is via pg module in NodeJS). After spending half a day looking for error, I
> learned from the javascript module developer that the mentioned syntax
> cannot be used for programmatic access. Instead, he recommended to use cast
> operator form '2019-01-20 08:00'::timestamp.
> I tested his suggestion (it works, of course) and was looking for some
> mention or confirmation in the documentation, but found nothing. I think
> this is a serious issue, especially because the alternative possibility of
> using ::timestamp is not even mentioned in chapters 8.5 or 9.9. If someone
> (like me) looks for specific information how to handle date & time literals,
> they will inevitably fall into the same trap.
> Since the experienced Syntax error is contrary to what one would expect
> after reading the SQL language manual, could you please at least add some
> hyperlink in both sections 8.5 and 9.9 to attract reader's attention to this
> specific behavior of the database server? Thank you.

We don't get this question very often.  I wonder if you didn't look at
the error message we generated, or if you could share the exact error
you saw.

-- 
  Bruce Momjian  <bruce@momjian.us>        http://momjian.us
  EnterpriseDB                             http://enterprisedb.com

+ As you are, so once was I.  As I am, so you will be. +
+                      Ancient Roman grave inscription +

On Tue, Apr  9, 2019 at 02:50:14PM +0000, PG Doc comments form wrote:
> The following documentation comment has been logged on the website:
>
I think
> this is a serious issue, especially because the alternative possibility of
> using ::timestamp is not even mentioned in chapters 8.5 or 9.9. If someone
> (like me) looks for specific information how to handle date & time literals,
> they will inevitably fall into the same trap.
> Since the experienced Syntax error is contrary to what one would expect
> after reading the SQL language manual, could you please at least add some
> hyperlink in both sections 8.5 and 9.9 to attract reader's attention to this
> specific behavior of the database server? Thank you.

We don't get this question very often.  I wonder if you didn't look at
the error message we generated, or if you could share the exact error
you saw.