Subject: Re: Allow to_date() and to_timestamp() to accept localized names
To: Tom Lane <tgl@sss.pgh.pa.us>,
 =?UTF-8?Q?Juan_Jos=c3=a9_Santamar=c3=ada_Flecha?=
 <juanjo.santamaria@gmail.com>
Cc: Tomas Vondra <tomas.vondra@2ndquadrant.com>,
 Alvaro Herrera <alvherre@2ndquadrant.com>,
 PostgreSQL Hackers <pgsql-hackers@lists.postgresql.org>
References: 
 <CAC+AXB2JOe4Dw1teZP-N-isNyDdY3F96oGFVYFxhmWtsbgi=ig@mail.gmail.com>
 <20190925195745.GA21894@alvherre.pgsql>
 <CAC+AXB12A7Fr9djoq7f1-WYesnZTRKpGpHM12MRG+M00mewN9g@mail.gmail.com>
 <20200111160602.4wwvyl7lo3oxoewf@development>
 <CAC+AXB1rLC7Gu7-fTQPNwSY9sFC9hkpn8_J3WyGwaKXvNZnoVQ@mail.gmail.com>
 <ba6fa1fd-ad60-d1ea-7226-676790c108ca@gmail.com>
 <CAC+AXB2a6ei0mPFG7h-NaiBVO5=tKT67rONZmrDzoOcAE-B2Sg@mail.gmail.com>
 <31691.1579648824@sss.pgh.pa.us> <29432.1579731087@sss.pgh.pa.us>
From: Arthur Zakirov <zaartur@gmail.com>
Message-ID: <cfa38397-9fe6-70f2-e081-9aa85eb5942e@gmail.com>
Date: Thu, 23 Jan 2020 12:17:22 +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: <29432.1579731087@sss.pgh.pa.us>
Content-Type: multipart/mixed;
 boundary="------------F6655A3B03F7D9891EBAC015"
Content-Language: en-US
Precedence: bulk

This is a multi-part message in MIME format.
--------------F6655A3B03F7D9891EBAC015
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 8bit

On 2020/01/23 7:11, Tom Lane wrote:
> Closer examination shows that the "max" argument is pretty bogus as
> well.  It doesn't do anything except confuse the reader, because there
> are no cases where the value passed is less than the maximum array entry
> length, so it never acts to change seq_search's behavior.  So we should
> just drop that behavior from seq_search, too, and redefine "max" as
> having no purpose except to specify how much of the string to show in
> error messages.  There's still a question of what that should be for
> non-English cases, but at least we now have a clear idea of what we
> need the value to do.

Shouldn't we just show all remaining string instead of truncating it? 
For example I get the following output:

=# select to_timestamp('3 ЯНВАРЯ 1999', 'DD MONTH YYYY');
ERROR:  invalid value "ЯНВА" for "MONTH"
DETAIL:  The given value did not match any of the allowed values for 
this field.

This behavior is reproduced without the patch though (on Postgres 12).

And the English case might confuse too I think:

=# select to_date('3 JANUZRY 1999', 'DD MONTH YYYY');
ERROR:  invalid value "JANUZRY 1" for "MONTH"
DETAIL:  The given value did not match any of the allowed values for 
this field.

Users might think what means "1" in "JANUZRY 1" string.

I attached the draft patch, which shows all remaining string. So the 
query above will show the following:

=# select to_timestamp('3 ЯНВАРЯ 1999', 'DD MONTH YYYY');
ERROR:  invalid value "ЯНВАРЯ 1999" for "MONTH"
DETAIL:  The remaining value did not match any of the allowed values for 
this field.

> The 0001 patch attached cleans up all the above complaints.  I felt
> that given the business about scribbling on strings we shouldn't,
> it would also be wise to const-ify the string pointers if possible.
> That seems not too painful, per 0002 attached.

+1 on the patch.

-- 
Arthur

--------------F6655A3B03F7D9891EBAC015
Content-Type: text/plain; charset=UTF-8;
 name="0003-formatting-show-remaining.patch"
Content-Transfer-Encoding: base64
Content-Disposition: attachment;
 filename="0003-formatting-show-remaining.patch"

ZGlmZiAtLWdpdCBhL3NyYy9iYWNrZW5kL3V0aWxzL2FkdC9mb3JtYXR0aW5nLmMgYi9zcmMv
YmFja2VuZC91dGlscy9hZHQvZm9ybWF0dGluZy5jCmluZGV4IGVmMjFiN2U0MjYuLjYzZTc3
M2M0YzEgMTAwNjQ0Ci0tLSBhL3NyYy9iYWNrZW5kL3V0aWxzL2FkdC9mb3JtYXR0aW5nLmMK
KysrIGIvc3JjL2JhY2tlbmQvdXRpbHMvYWR0L2Zvcm1hdHRpbmcuYwpAQCAtMjUzOSwxNyAr
MjUzOSwxMSBAQCBmcm9tX2NoYXJfc2VxX3NlYXJjaChpbnQgKmRlc3QsIGNvbnN0IGNoYXIg
KipzcmMsIGNvbnN0IGNoYXIgKmNvbnN0ICphcnJheSwKIAogCWlmIChsZW4gPD0gMCkKIAl7
Ci0JCWNoYXIJCWNvcHlbRENIX01BWF9JVEVNX1NJWiArIDFdOwotCi0JCS8qIFVzZSBtdWx0
aWJ5dGUtYXdhcmUgdHJ1bmNhdGlvbiB0byBhdm9pZCBnZW5lcmF0aW5nIGEgYm9ndXMgc3Ry
aW5nICovCi0JCW1heCA9IHBnX21iY2xpcGxlbigqc3JjLCBzdHJsZW4oKnNyYyksIG1heCk7
Ci0JCXN0cmxjcHkoY29weSwgKnNyYywgbWF4ICsgMSk7Ci0KIAkJUkVUVVJOX0VSUk9SKGVy
ZXBvcnQoRVJST1IsCiAJCQkJCQkJIChlcnJjb2RlKEVSUkNPREVfSU5WQUxJRF9EQVRFVElN
RV9GT1JNQVQpLAogCQkJCQkJCSAgZXJybXNnKCJpbnZhbGlkIHZhbHVlIFwiJXNcIiBmb3Ig
XCIlc1wiIiwKLQkJCQkJCQkJCSBjb3B5LCBub2RlLT5rZXktPm5hbWUpLAotCQkJCQkJCSAg
ZXJyZGV0YWlsKCJUaGUgZ2l2ZW4gdmFsdWUgZGlkIG5vdCBtYXRjaCBhbnkgb2YgIgorCQkJ
CQkJCQkJICpzcmMsIG5vZGUtPmtleS0+bmFtZSksCisJCQkJCQkJICBlcnJkZXRhaWwoIlRo
ZSByZW1haW5pbmcgdmFsdWUgZGlkIG5vdCBtYXRjaCBhbnkgb2YgIgogCQkJCQkJCQkJCSJ0
aGUgYWxsb3dlZCB2YWx1ZXMgZm9yIHRoaXMgZmllbGQuIikpKSk7CiAJfQogCSpzcmMgKz0g
bGVuOwo=
--------------F6655A3B03F7D9891EBAC015--