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 1jjrDu-0000AG-AN for pgsql-docs@arkaria.postgresql.org; Fri, 12 Jun 2020 21:28:26 +0000 Received: from localhost ([127.0.0.1] helo=malur.postgresql.org) by malur.postgresql.org with esmtp (Exim 4.92) (envelope-from ) id 1jjrDs-0000bi-Eh for pgsql-docs@arkaria.postgresql.org; Fri, 12 Jun 2020 21:28:24 +0000 Received: from makus.postgresql.org ([2001:4800:3e1:1::229]) by malur.postgresql.org with esmtps (TLS1.3:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.92) (envelope-from ) id 1jjrDs-0000bb-9A for pgsql-docs@lists.postgresql.org; Fri, 12 Jun 2020 21:28:24 +0000 Received: from momjian.us ([72.94.173.45]) by makus.postgresql.org with esmtps (TLS1.3:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.92) (envelope-from ) id 1jjrDp-0002Ia-UK for pgsql-docs@lists.postgresql.org; Fri, 12 Jun 2020 21:28:23 +0000 Received: from bruce by momjian.us with local (Exim 4.92) (envelope-from ) id 1jjrDn-0003K1-4h; Fri, 12 Jun 2020 17:28:19 -0400 Date: Fri, 12 Jun 2020 17:28:19 -0400 From: Bruce Momjian To: 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: <20200612212819.GA6813@momjian.us> References: <159135581922.7031.8149548798892105892@wrigleys.postgresql.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <159135581922.7031.8149548798892105892@wrigleys.postgresql.org> 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 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 https://momjian.us EnterpriseDB https://enterprisedb.com The usefulness of a cup is in its emptiness, Bruce Lee