Received: from malur.postgresql.org ([217.196.149.56]) by arkaria.postgresql.org with esmtp (Exim 4.84_2) (envelope-from ) id 1bF0vj-0003Ew-91 for pgsql-hackers@arkaria.postgresql.org; Mon, 20 Jun 2016 15:16:03 +0000 Received: from localhost ([127.0.0.1] helo=postgresql.org) by malur.postgresql.org with smtp (Exim 4.84_2) (envelope-from ) id 1bF0vi-0002AH-3m for pgsql-hackers@arkaria.postgresql.org; Mon, 20 Jun 2016 15:16:02 +0000 Received: from magus.postgresql.org ([2a02:c0:301:0:ffff::29]) by malur.postgresql.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_CBC_SHA384:256) (Exim 4.84_2) (envelope-from ) id 1bF0vh-0002AB-Hz for pgsql-hackers@postgresql.org; Mon, 20 Jun 2016 15:16:01 +0000 Received: from newmail.postgrespro.ru ([93.174.131.138] helo=mail.postgrespro.ru) by magus.postgresql.org with esmtp (Exim 4.84_2) (envelope-from ) id 1bF0va-00074G-8e for pgsql-hackers@postgresql.org; Mon, 20 Jun 2016 15:16:00 +0000 Received: from localhost (localhost [127.0.0.1]) by mail.postgrespro.ru (Postfix) with ESMTP id F262521C8EE2; Mon, 20 Jun 2016 18:15:52 +0300 (MSK) X-Virus-Scanned: Debian amavisd-new at postgrespro.ru Received: from mail.postgrespro.ru ([127.0.0.1]) by localhost (mail.postgrespro.ru [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id QG-UbbvJuaEO; Mon, 20 Jun 2016 18:15:49 +0300 (MSK) Received: from [192.168.27.30] (unknown [192.168.27.1]) by mail.postgrespro.ru (Postfix) with ESMTPSA id 8C0E021C8EC6; Mon, 20 Jun 2016 18:15:49 +0300 (MSK) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=postgrespro.ru; s=mail; t=1466435749; bh=Vt2sYkvEmodxRBVEBp93zjYdQeTBNpFgfs0T7XY92kU=; h=Subject:To:References:Cc:From:Date:In-Reply-To; b=nwvDaPBu3q3Vd8ErT0+/OA2VFq2G5hPJzYWwG5xaQ4n1yKP1EgLxyyZEFRFrZri9W 9I0iT00DGymtIQ8dXILHaqvCmG0JZvgk8H59mWXO80lgcg9FLX0GLbQyHoxiRCcIXA UW55dO+0MJ21rLnLfPKriMSjJGzJ2w6+1iXAG4HU= Subject: Re: Bug in to_timestamp(). To: Tom Lane , Robert Haas References: <1873520224.1784572.1465833145330.JavaMail.yahoo.ref@mail.yahoo.com> <1873520224.1784572.1465833145330.JavaMail.yahoo@mail.yahoo.com> <20932.1465834344@sss.pgh.pa.us> <11349.1466429771@sss.pgh.pa.us> Cc: amul sul , PostgreSQL-development From: Alex Ignatov Message-ID: <0f8caaa5-9d9d-ff3f-a7a3-223aefc96da4@postgrespro.ru> Date: Mon, 20 Jun 2016 18:15:50 +0300 User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:45.0) Gecko/20100101 Thunderbird/45.1.1 MIME-Version: 1.0 In-Reply-To: <11349.1466429771@sss.pgh.pa.us> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit X-Pg-Spam-Score: -3.4 (---) 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 On 20.06.2016 16:36, Tom Lane wrote: > Robert Haas writes: >> On Mon, Jun 13, 2016 at 12:25 PM, Robert Haas wrote: >>> I think a space in the format string should skip a whitespace >>> character in the input string, but not a non-whitespace character. >>> It's my understanding that these functions exist in no small part for >>> compatibility with Oracle, and Oracle declines to skip the digit '1' >>> on the basis of an extra space in the format string, which IMHO is the >>> behavior any reasonable user would expect. >> So Amul and I are of one opinion and Tom is of another. Anyone else >> have an opinion? > I don't necessarily have an opinion yet. I would like to see more than > just an unsupported assertion about what Oracle's behavior is. Also, > how should FM mode affect this? > > regards, tom lane > > Oracle: SQL> SELECT TO_TIMESTAMP('2016-06-13 99:99:99', 'YYYYMMDD HH24:MI:SS') from dual; SELECT TO_TIMESTAMP('2016-06-13 99:99:99', 'YYYYMMDD HH24:MI:SS') from dual * ERROR at line 1: ORA-01843: not a valid month PG: postgres=# SELECT TO_TIMESTAMP('2016-06-13 99:99:99', 'YYYYMMDD HH24:MI:SS'); to_timestamp ------------------------ 2016-01-06 14:40:39+03 (1 row) I know about: "These functions interpret input liberally, with minimal error checking. While they produce valid output, the conversion can yield unexpected results" from docs but by providing illegal input parameters we have no any exceptions or errors about that. I think that to_timestamp() need to has more format checking than it has now. Alex Ignatov Postgres Professional: http://www.postgrespro.com The Russian Postgres Company -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers