Received: from malur.postgresql.org ([217.196.149.56]) by arkaria.postgresql.org with esmtp (Exim 4.84_2) (envelope-from ) id 1bG8eC-0001r5-2W for pgsql-hackers@arkaria.postgresql.org; Thu, 23 Jun 2016 17:42:36 +0000 Received: from localhost ([127.0.0.1] helo=postgresql.org) by malur.postgresql.org with smtp (Exim 4.84_2) (envelope-from ) id 1bG8eB-0003e4-7R for pgsql-hackers@arkaria.postgresql.org; Thu, 23 Jun 2016 17:42:35 +0000 Received: from makus.postgresql.org ([2001:4800:1501:1::229]) by malur.postgresql.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_CBC_SHA384:256) (Exim 4.84_2) (envelope-from ) id 1bG8cp-0002A7-Jn for pgsql-hackers@postgresql.org; Thu, 23 Jun 2016 17:41:11 +0000 Received: from sss.pgh.pa.us ([66.207.139.130]) by makus.postgresql.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_CBC_SHA384:256) (Exim 4.84_2) (envelope-from ) id 1bG8cj-0002Dw-79 for pgsql-hackers@postgresql.org; Thu, 23 Jun 2016 17:41:10 +0000 Received: from sss1.sss.pgh.pa.us (localhost [127.0.0.1]) by sss.pgh.pa.us (8.14.4/8.14.4) with ESMTP id u5NHetDJ031916; Thu, 23 Jun 2016 13:40:55 -0400 From: Tom Lane To: Robert Haas cc: "David G. Johnston" , Alex Ignatov , Bruce Momjian , amul sul , PostgreSQL-development Subject: Re: Bug in to_timestamp(). In-reply-to: References: <1873520224.1784572.1465833145330.JavaMail.yahoo.ref@mail.yahoo.com> <1873520224.1784572.1465833145330.JavaMail.yahoo@mail.yahoo.com> <884791796.213185.1466667686999.JavaMail.yahoo@mail.yahoo.com> <20160623133001.GF21246@momjian.us> <1877e60a-a970-18b5-453c-e342f96150e6@postgrespro.ru> Comments: In-reply-to Robert Haas message dated "Thu, 23 Jun 2016 13:20:46 -0400" Date: Thu, 23 Jun 2016 13:40:55 -0400 Message-ID: <31915.1466703655@sss.pgh.pa.us> X-Pg-Spam-Score: -3.3 (---) List-Archive: List-Help: List-ID: List-Owner: List-Post: List-Subscribe: List-Unsubscribe: X-Mailing-List: pgsql-hackers Precedence: bulk Sender: pgsql-hackers-owner@postgresql.org Robert Haas writes: > On Thu, Jun 23, 2016 at 1:12 PM, David G. Johnston > wrote: >> My understanding is that is not going to change for 9.6. > That's exactly what is under discussion here. I would definitely agree with David on that point. Making to_timestamp noticeably better on this score seems like a nontrivial project, and post-beta is not the time for that sort of thing, even if we had full consensus on what to do. I'd suggest somebody work on a patch and put it up for review in the next cycle. Now, if you were to narrowly define the problem as "whether to skip non-spaces for a space in the format", maybe that could be fixed post-beta, but I think that's a wrongheaded approach. to_timestamp's issues with input that doesn't match the format are far wider than that. IMO we should try to resolve the whole problem with one coherent change, not make incremental incompatible changes at the margins. At the very least I'd want to see a thought-through proposal that addresses all three of these interrelated points: * what should a space in the format match * what should a non-space, non-format-code character in the format match * how should we handle fields that are not exactly the width suggested by the format regards, tom lane -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers