From: | "David G(dot) Johnston" <david(dot)g(dot)johnston(at)gmail(dot)com> |
---|---|
To: | Bruce Momjian <bruce(at)momjian(dot)us> |
Cc: | ehansmair(at)prompt-software(dot)de, pgsql-docs(at)lists(dot)postgresql(dot)org |
Subject: | Re: Documentation 9.8. Data Type Formatting Functions: missing behaviour on invalid input at to_date() |
Date: | 2020-06-12 21:47:29 |
Message-ID: | CAKFQuwYz3qhNTqAv0K7jdeG+iDbeRno9J2pCZ5YRW1QNY7ewWw@mail.gmail.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-docs |
On Fri, Jun 12, 2020 at 2:28 PM Bruce Momjian <bruce(at)momjian(dot)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.
From | Date | Subject | |
---|---|---|---|
Next Message | Bruce Momjian | 2020-06-13 13:45:52 | Re: Documentation 9.8. Data Type Formatting Functions: missing behaviour on invalid input at to_date() |
Previous Message | Bruce Momjian | 2020-06-12 21:29:51 | Re: create database with template doesn't copy ACL |