Re: Documentation 9.8. Data Type Formatting Functions: missingbehaviour on invalid input at to_date() - Mailing list pgsql-docs

From David G. Johnston
Subject Re: Documentation 9.8. Data Type Formatting Functions: missingbehaviour on invalid input at to_date()
Date
Msg-id CAKFQuwYz3qhNTqAv0K7jdeG+iDbeRno9J2pCZ5YRW1QNY7ewWw@mail.gmail.com
Whole thread Raw
In response to Re: Documentation 9.8. Data Type Formatting Functions: missingbehaviour on invalid input at to_date()  (Bruce Momjian <bruce@momjian.us>)
Responses Re: Documentation 9.8. Data Type Formatting Functions: missingbehaviour on invalid input at to_date()
List pgsql-docs
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.

pgsql-docs by date:

Previous
From: Bruce Momjian
Date:
Subject: Re: create database with template doesn't copy ACL
Next
From: Bruce Momjian
Date:
Subject: Re: Documentation 9.8. Data Type Formatting Functions: missingbehaviour on invalid input at to_date()