RE: Confusing information in sections 8.5 and 9.9 (date and time types, functions and operators)

Hello,
I thought about it once more.
I think I fell into trap of my own experience. I do not work with PG very often, that’s why I went into the manual to make sure what is the actual syntax. Second, in most cases in my professional use of any rdbms, we work with scripts (or PL/SQL procedures) and never use database API (my specialization are data warehouses). That’s probably why I never really cared if there were any differences in SQL between script execution and API call.
This was a use case that went out of my usual experience and that’s why I made a mistake that very few active developers or users of PostgreSQL can understand 😊
You guys decide if this single case requires any fixes in docs. If this has never happened in the last ten years, probably not.
Regards,
Jindra

From: David G. Johnston <david(dot)g(dot)johnston(at)gmail(dot)com>
Sent: Saturday, April 13, 2019 9:31 AM
To: Bruce Momjian <bruce(at)momjian(dot)us>
Cc: jindrich(at)vavruska(dot)cz; pgsql-docs(at)lists(dot)postgresql(dot)org
Subject: Re: Confusing information in sections 8.5 and 9.9 (date and time types, functions and operators)

On Friday, April 12, 2019, Bruce Momjian <bruce(at)momjian(dot)us<mailto:bruce(at)momjian(dot)us>> wrote:
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.

See also:

https://www.postgresql.org/message-id/flat/CAKFQuwYXhvhr8hWd1ZjWedediHiC2pY4SrvOwSNDVu8sguBhdQ%40mail.gmail.com#c18e77160d396e00d4d9f097f4294a7d<https://nam03.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.postgresql.org%2Fmessage-id%2Fflat%2FCAKFQuwYXhvhr8hWd1ZjWedediHiC2pY4SrvOwSNDVu8sguBhdQ%2540mail.gmail.com%23c18e77160d396e00d4d9f097f4294a7d&data=02%7C01%7C%7C0cf3a6235f94414c6a8008d6bfe1f6e8%7C84df9e7fe9f640afb435aaaaaaaaaaaa%7C1%7C0%7C636907374557077068&sdata=9sqzjZ9xYcXgTTHlnwB6xSCmQr5W20g%2Bj%2BN31VcNap4%3D&reserved=0>

The docs maybe aren’t great at covering this but they do, and correctly. Though maybe a note saying “this works but you probably should use actual casts” would be warranted. I personally have not found a need to use the “type” ‘literal’ syntax.

David J.