Documentation 9.8. Data Type Formatting Functions: missing behaviour on invalid input at to_date()
The following documentation comment has been logged on the website:
Page: https://www.postgresql.org/docs/12/functions-formatting.html
Description:
For the formatting functions, which convert between a string and a type like
date, timestamp or number, there should be a description about the behaviour
of i.e. to_date(input, mask) in case of invalid, not convertable input.
I expected a return value of NULL and got a execution error.
On Fri, Jun 5, 2020 at 11:16:59AM +0000, PG Doc comments form wrote:
The following documentation comment has been logged on the website:
Page: https://www.postgresql.org/docs/12/functions-formatting.html
Description:For the formatting functions, which convert between a string and a type like
date, timestamp or number, there should be a description about the behaviour
of i.e. to_date(input, mask) in case of invalid, not convertable input.I expected a return value of NULL and got a execution error.
Well, the value isn't "unknown", it is invalid, so an error seems
appropriate. I don't remember anyone complaining the expected a NULL
return.
--
Bruce Momjian <bruce@momjian.us> https://momjian.us
EnterpriseDB https://enterprisedb.com
The usefulness of a cup is in its emptiness, Bruce Lee
On Fri, Jun 12, 2020 at 2:28 PM Bruce Momjian <bruce@momjian.us> wrote:
On Fri, Jun 5, 2020 at 11:16:59AM +0000, PG Doc comments form wrote:
The following documentation comment has been logged on the website:
Page: https://www.postgresql.org/docs/12/functions-formatting.html
Description:For the formatting functions, which convert between a string and a type
like
date, timestamp or number, there should be a description about the
behaviour
of i.e. to_date(input, mask) in case of invalid, not convertable input.
I expected a return value of NULL and got a execution error.
Well, the value isn't "unknown", it is invalid, so an error seems
appropriate. I don't remember anyone complaining the expected a NULL
return.
The complaint is about us not explicitly documenting which of "error" or
"null" is the outcome so the reader is left to assume or test it
themselves. The OP isn't saying our choice is wrong, just our lack of
documentation of said choice.
I believe the current reality is the user should assume that problems
result in errors unless the function documents that it will return NULL.
David J.
On Fri, Jun 12, 2020 at 02:47:29PM -0700, David G. Johnston wrote:
On Fri, Jun 12, 2020 at 2:28 PM Bruce Momjian <bruce@momjian.us> wrote:
On Fri, Jun� 5, 2020 at 11:16:59AM +0000, PG Doc comments form wrote:
The following documentation comment has been logged on the website:
Page: https://www.postgresql.org/docs/12/functions-formatting.html
Description:For the formatting functions, which convert between a string and a type
like
date, timestamp or number, there should be a description about the
behaviour
of i.e. to_date(input, mask) in case of invalid, not convertable input.
I expected a return value of NULL and got a execution error.
Well, the value isn't "unknown", it is invalid, so an error seems
appropriate.� I don't remember anyone complaining the expected a NULL
return.The complaint is about us not explicitly documenting which of "error" or "null"
is the outcome so the reader is left to assume or test it themselves.� The OP
isn't saying our choice is wrong, just our lack of documentation of said
choice.I believe the current reality is the user should assume that problems result�in
errors unless the function documents that it will return NULL.
Yeah, it would be annoying to have to read that invalid input returns an
error and not null in every place this happens.
--
Bruce Momjian <bruce@momjian.us> https://momjian.us
EnterpriseDB https://enterprisedb.com
The usefulness of a cup is in its emptiness, Bruce Lee