Subject: Re: Allow to_date() and to_timestamp() to accept localized names
To: =?UTF-8?Q?Juan_Jos=c3=a9_Santamar=c3=ada_Flecha?=
 <juanjo.santamaria@gmail.com>, Mark Dilger <mark.dilger@enterprisedb.com>
References: <20200124161814.GA8989@alvherre.pgsql>
 <32487.1579882979@sss.pgh.pa.us>
 <2f83150e-a2c0-6318-3125-d9b86e421aa2@2ndquadrant.com>
 <964.1579884408@sss.pgh.pa.us>
 <CAC+AXB1+dHo_DhCTySrqoVaq9WUta9uA+2Ens-bEqDw8X4UbTA@mail.gmail.com>
 <ba83b5a7-e63e-5aaf-ac29-745a549f9d7d@2ndquadrant.com>
 <aa5d8d96-0eb6-07b9-2caf-0910b313cb56@2ndquadrant.com>
 <7212.1580177517@sss.pgh.pa.us>
 <2E3D8D71-3B55-4735-A047-1FECE1506CD1@enterprisedb.com>
 <d2b20ae0-a377-5edc-504b-80b1792a6bf0@2ndquadrant.com>
 <6642.1580223087@sss.pgh.pa.us>
 <4144A0A0-4820-458D-A105-D5EC0E0D133B@enterprisedb.com>
 <CAC+AXB2uTOaPQ2cxvjgcGF3kRVCucftFwchZdQ5n_F0R+P7KwA@mail.gmail.com>
Cc: Tom Lane <tgl@sss.pgh.pa.us>, Alvaro Herrera <alvherre@2ndquadrant.com>,
 Arthur Zakirov <zaartur@gmail.com>,
 Tomas Vondra <tomas.vondra@2ndquadrant.com>,
 PostgreSQL Hackers <pgsql-hackers@lists.postgresql.org>
From: Peter Eisentraut <peter.eisentraut@2ndquadrant.com>
Organization: 2ndQuadrant
Message-ID: <dae3654e-aee2-b691-ec82-f8dc43ebfd14@2ndquadrant.com>
Date: Tue, 28 Jan 2020 21:35:25 +0100
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.14; rv:52.0)
 Gecko/20100101 Thunderbird/52.9.1
MIME-Version: 1.0
In-Reply-To: 
 <CAC+AXB2uTOaPQ2cxvjgcGF3kRVCucftFwchZdQ5n_F0R+P7KwA@mail.gmail.com>
Content-Type: text/plain; charset=utf-8; format=flowed
Content-Language: en-US
Content-Transfer-Encoding: 8bit
Precedence: bulk

On 2020-01-28 16:47, Juan José Santamaría Flecha wrote:
> This patch targets to do something symmetrical to to_char(), which will 
> just return a single value.

I didn't fully realize while reading this thread that to_char() already 
supports localized output and this patch indeed just wants to do the 
opposite.

So I'm withdrawing my concerns with respect to this patch.  As long as 
it can do a roundtrip conversion with to_char(), it's fine.

It's pretty clear that this interface cannot be useful for producing or 
parsing fully general localized dates.  But since it exists now (and 
it's quasi SQL standard now), we might as well fill in this gap.

-- 
Peter Eisentraut              http://www.2ndQuadrant.com/
PostgreSQL Development, 24x7 Support, Remote DBA, Training & Services