Received: from malur.postgresql.org ([217.196.149.56]) by arkaria.postgresql.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_CBC_SHA1:256) (Exim 4.89) (envelope-from ) id 1irfmw-0008Cy-PJ for pgsql-hackers@arkaria.postgresql.org; Wed, 15 Jan 2020 10:20:38 +0000 Received: from localhost ([127.0.0.1] helo=malur.postgresql.org) by malur.postgresql.org with esmtp (Exim 4.89) (envelope-from ) id 1irfmu-0006do-Lz for pgsql-hackers@arkaria.postgresql.org; Wed, 15 Jan 2020 10:20:36 +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_SHA1:256) (Exim 4.89) (envelope-from ) id 1irfmu-0006ae-AN for pgsql-hackers@lists.postgresql.org; Wed, 15 Jan 2020 10:20:36 +0000 Received: from mail-pf1-x42f.google.com ([2607:f8b0:4864:20::42f]) by magus.postgresql.org with esmtps (TLS1.3:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.92) (envelope-from ) id 1irfmo-0008HW-Bj for pgsql-hackers@lists.postgresql.org; Wed, 15 Jan 2020 10:20:35 +0000 Received: by mail-pf1-x42f.google.com with SMTP id 4so8313224pfz.9 for ; Wed, 15 Jan 2020 02:20:29 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=subject:to:cc:references:from:message-id:date:user-agent :mime-version:in-reply-to:content-language:content-transfer-encoding; bh=kfAXKFzyx86xZ27mMOd3svzE9sIm/AeswhnmoUbrP2k=; b=TC/Ilxsj5S1s9ayrKzyslZsU+MSzC4F/+h+W9TpdD3ylOrR/AGO53dU9gnUHpvLokB PLYpMAWO0h4yWl1Ci/2OmlJp8kaEFCpyFEJTnrqyuDjcc7h1e+7qbaPp+BbY21JCUEJS f5z71VcY6fHAZzsWJWFa/paE/JOvraF/R7QwVJIKq7ArqOVlq8VCjVyC+HDa6UJ1lqJc ww8DojHqYGeIAdSN+CwPVAPuDRCUxjlZMXU2f+IFXRDl9GUzFSq0rtTAxLS+4YNOoLf1 b3BqkwVtu3uDAmbGUM8DDen+lJVkwwFv2FxGGIIQUMEDLUTqvH68YQQtTKAViCTS03vI RL/Q== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:subject:to:cc:references:from:message-id:date :user-agent:mime-version:in-reply-to:content-language :content-transfer-encoding; bh=kfAXKFzyx86xZ27mMOd3svzE9sIm/AeswhnmoUbrP2k=; b=JkiscH76JMwvoDtu+O5ReyX91Vpm5alQb2nisXD7GQqxQmprZw0zsqGwLCWBS3PaA+ 9Cwi50huU9iecpPfeWUNxUR9qrhJ9jrkNXC/wjn8C9vgpQU0vCxa6Tl34Mn8rqb7Hy64 0t6CVdy/cVY+CDoau7XKI0SJ7gP89q7/RugUJC2lGDAE+Zqb6Qcg5K2KIQ/jfvSmPp80 K3yav8GXCxNF1sRaz49AGwu4HMSU3upMDwyi83ZytXRBoLN6qbynyOznT/1wnkbXUj8/ ZROsClMMWRn9G+BWUC9G8biKDpZyeK77PRcBf0hbaTBtqicSpjMpdfzLbP9qi8Hc2hX3 cwcg== X-Gm-Message-State: APjAAAW2LyAc1VkqKTIkOkt0FEtJ4a+apoquEm6Bsvl3iM99cP0HWQJZ 058zZUq7dCCPnroTONPdQ7hdlVpr X-Google-Smtp-Source: APXvYqxrWbEi/rlheDWteXm0xAcQyr0B8W8XWOItBbud0FH2dDUApm/xoNK5H8T4M1MJ9o7H20YeVA== X-Received: by 2002:aa7:8749:: with SMTP id g9mr6524575pfo.40.1579083627742; Wed, 15 Jan 2020 02:20:27 -0800 (PST) Received: from [192.168.2.111] (113x32x180x194.ap113.ftth.ucom.ne.jp. [113.32.180.194]) by smtp.gmail.com with ESMTPSA id v4sm20857196pff.174.2020.01.15.02.20.25 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Wed, 15 Jan 2020 02:20:27 -0800 (PST) Subject: Re: Allow to_date() and to_timestamp() to accept localized names To: =?UTF-8?Q?Juan_Jos=c3=a9_Santamar=c3=ada_Flecha?= , Tomas Vondra Cc: Alvaro Herrera , PostgreSQL Hackers References: <20190925195745.GA21894@alvherre.pgsql> <20200111160602.4wwvyl7lo3oxoewf@development> From: Arthur Zakirov Message-ID: Date: Wed, 15 Jan 2020 19:20:25 +0900 User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:68.0) Gecko/20100101 Thunderbird/68.3.1 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: en-US Content-Transfer-Encoding: 8bit List-Id: List-Help: List-Subscribe: List-Post: List-Owner: List-Archive: Precedence: bulk Hello! On 2020/01/13 21:04, Juan José Santamaría Flecha wrote: > Please, find attached a version addressing the above mentioned. I have some couple picky notes. > + if (name_len != norm_len) > + pfree(norm_name); I'm not sure here. Is it save to assume that if it was allocated a new norm_name name_len and norm_len always will differ? > static const char *const months_full[] = { > "January", "February", "March", "April", "May", "June", "July", > - "August", "September", "October", "November", "December", NULL > + "August", "September", "October", "November", "December" > }; Unfortunately I didn't see from the patch why it was necessary to remove last null element from months_full, days_short, adbc_strings, adbc_strings_long and other arrays. I think it is not good because unnecessarily increases the patch and adds code like the following: > + from_char_seq_search(&value, &s, months, localized_names, > + ONE_UPPER, MAX_MON_LEN, n, have_error, > + lengthof(months_full)); Here it passes "months" from datetime.c to from_char_seq_search() and calculates its length using "months_full" array from formatting.c. -- Arthur