Received: from malur.postgresql.org ([217.196.149.56]) by arkaria.postgresql.org with esmtps (TLS1.3:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.92) (envelope-from ) id 1jk6Tx-0006mN-2V for pgsql-docs@arkaria.postgresql.org; Sat, 13 Jun 2020 13:46:01 +0000 Received: from localhost ([127.0.0.1] helo=malur.postgresql.org) by malur.postgresql.org with esmtp (Exim 4.92) (envelope-from ) id 1jk6Tu-00042K-Cq for pgsql-docs@arkaria.postgresql.org; Sat, 13 Jun 2020 13:45:58 +0000 Received: from magus.postgresql.org ([2a02:c0:301:0:ffff::29]) by malur.postgresql.org with esmtps (TLS1.3:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.92) (envelope-from ) id 1jk6Tu-00042D-6r for pgsql-docs@lists.postgresql.org; Sat, 13 Jun 2020 13:45:58 +0000 Received: from momjian.us ([72.94.173.45]) by magus.postgresql.org with esmtps (TLS1.3:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.92) (envelope-from ) id 1jk6Ts-0004aB-Bd for pgsql-docs@lists.postgresql.org; Sat, 13 Jun 2020 13:45:57 +0000 Received: from bruce by momjian.us with local (Exim 4.92) (envelope-from ) id 1jk6To-0000dN-CV; Sat, 13 Jun 2020 09:45:52 -0400 Date: Sat, 13 Jun 2020 09:45:52 -0400 From: Bruce Momjian To: "David G. Johnston" Cc: ehansmair@prompt-software.de, pgsql-docs@lists.postgresql.org Subject: Re: Documentation 9.8. Data Type Formatting Functions: missing behaviour on invalid input at to_date() Message-ID: <20200613134552.GB20551@momjian.us> References: <159135581922.7031.8149548798892105892@wrigleys.postgresql.org> <20200612212819.GA6813@momjian.us> MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: User-Agent: Mutt/1.10.1 (2018-07-13) List-Id: List-Help: List-Subscribe: List-Post: List-Owner: List-Archive: Precedence: bulk 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 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 https://momjian.us EnterpriseDB https://enterprisedb.com The usefulness of a cup is in its emptiness, Bruce Lee