On Sun, Mar 8, 2020 at 6:03 PM Tom Lane wrote:
> James Coleman writes:
> > So just to confirm I understand, that implies that the issue is solely
> that
> > only the utf8 tr_TR set is installed by default on this machine, and the
> > iso-8859-9 set is a hard requirement (that is, the test is exp
James Coleman writes:
> So just to confirm I understand, that implies that the issue is solely that
> only the utf8 tr_TR set is installed by default on this machine, and the
> iso-8859-9 set is a hard requirement (that is, the test is explicitly
> testing a codepath that generates utf8 results fr
On Sun, Mar 8, 2020 at 2:19 PM Tom Lane wrote:
> I wrote:
> > James Coleman writes:
> >> I'm still interested in understanding why we're using the ISO locale
> >> instead of the utf8 one in a utf8-labeled test though.
>
> > We are not. My understanding of the rules about this is that the
> > ac
I wrote:
> James Coleman writes:
>> I'm still interested in understanding why we're using the ISO locale
>> instead of the utf8 one in a utf8-labeled test though.
> We are not. My understanding of the rules about this is that the
> active LC_CTYPE setting determines the encoding that libc uses,
James Coleman writes:
> Since sudo dpkg-reconfigure locales opens up an ncurses gui on my machine,
> I tried selecting the tr_TR.ISO-8859-9 option there and removed the
> /var/lib/locales/supported.d/local file. Now I get:
> $ locale -a | grep tr_TR
> tr_TR
> tr_TR.iso88599
> tr_TR.utf8
> And no
On Sun, Mar 8, 2020 at 10:42 AM James Coleman wrote:
> On Sun, Mar 8, 2020 at 7:17 AM Juan José Santamaría Flecha <
> juanjo.santama...@gmail.com> wrote:
>
>>
>>
>> On Sun, Mar 8, 2020 at 3:48 AM Tom Lane wrote:
>>
>>> James Coleman writes:
>>> > On Sat, Mar 7, 2020 at 9:31 PM Tom Lane wrote:
On Sun, Mar 8, 2020 at 7:17 AM Juan José Santamaría Flecha <
juanjo.santama...@gmail.com> wrote:
>
>
> On Sun, Mar 8, 2020 at 3:48 AM Tom Lane wrote:
>
>> James Coleman writes:
>> > On Sat, Mar 7, 2020 at 9:31 PM Tom Lane wrote:
>> >> Looks like you may not have Turkish locale installed? Try
>
On Sat, Mar 7, 2020 at 9:48 PM Tom Lane wrote:
> James Coleman writes:
> > On Sat, Mar 7, 2020 at 9:31 PM Tom Lane wrote:
> >> Looks like you may not have Turkish locale installed? Try
> >> locale -a | grep tr_TR
>
> > Hmm, when I grep the locales I see `tr_TR.utf8` in the output. I assume
> t
On Sun, Mar 8, 2020 at 3:48 AM Tom Lane wrote:
> James Coleman writes:
> > On Sat, Mar 7, 2020 at 9:31 PM Tom Lane wrote:
> >> Looks like you may not have Turkish locale installed? Try
> >> locale -a | grep tr_TR
>
> > Hmm, when I grep the locales I see `tr_TR.utf8` in the output. I assume
> t
James Coleman writes:
> On Sat, Mar 7, 2020 at 9:31 PM Tom Lane wrote:
>> Looks like you may not have Turkish locale installed? Try
>> locale -a | grep tr_TR
> Hmm, when I grep the locales I see `tr_TR.utf8` in the output. I assume the
> utf8 version is acceptable? Or is there a non-utf8 varian
On Sat, Mar 7, 2020 at 9:31 PM Tom Lane wrote:
> James Coleman writes:
> > On master with a clean build (and configure re-run) and a fresh init-db,
> > I'm seeing the collate.linux.utf8 test fail with the attached diff.
>
> -- to_char
> SET lc_time TO 'tr_TR';
> +ERROR: invalid value for para
James Coleman writes:
> On master with a clean build (and configure re-run) and a fresh init-db,
> I'm seeing the collate.linux.utf8 test fail with the attached diff.
-- to_char
SET lc_time TO 'tr_TR';
+ERROR: invalid value for parameter "lc_time": "tr_TR"
SELECT to_char(date '2010-02-01', 'D
On Tue, Mar 3, 2020 at 11:09 AM Tom Lane wrote:
> =?UTF-8?Q?Juan_Jos=C3=A9_Santamar=C3=ADa_Flecha?= <
> juanjo.santama...@gmail.com> writes:
> > On Sun, Mar 1, 2020 at 11:25 PM Tom Lane wrote:
> >> Going once, going twice ...
>
> > You have moved this to better place, so none from me, and thank
=?UTF-8?Q?Juan_Jos=C3=A9_Santamar=C3=ADa_Flecha?=
writes:
> On Sun, Mar 1, 2020 at 11:25 PM Tom Lane wrote:
>> Going once, going twice ...
> You have moved this to better place, so none from me, and thank you.
Pushed then.
While looking over the patch one more time, I noticed some pretty poor
On Sun, Mar 1, 2020 at 11:25 PM Tom Lane wrote:
>
> > Barring objections, this seems
> > committable to me.
>
> Going once, going twice ...
>
You have moved this to better place, so none from me, and thank you.
Regards,
Juan José Santamaría Flecha
I wrote:
> * I don't think it's appropriate to hard-wire DEFAULT_COLLATION_OID
> as the collation to do case-folding with. For to_date/to_timestamp,
> we have collatable text input so we can rely on the function's input
> collation instead, at the cost of having to pass down the collation
> OID th
=?UTF-8?Q?Juan_Jos=C3=A9_Santamar=C3=ADa_Flecha?=
writes:
> On Tue, Jan 28, 2020 at 9:35 PM Peter Eisentraut <
> peter.eisentr...@2ndquadrant.com> wrote:
>> 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.
> We
On Tue, Jan 28, 2020 at 9:35 PM Peter Eisentraut <
peter.eisentr...@2ndquadrant.com> wrote:
> 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
On Tue, Jan 28, 2020 at 5:21 PM Alvaro Herrera
wrote:
> On 2020-Jan-28, Peter Eisentraut wrote:
>
> > On 2020-01-28 04:05, Mark Dilger wrote:
> > > German uses both Sonnabend and Samstag for Saturday, so don’t you have
> to compare to a list of values anyway?
> >
> > Yeah, good point. If it does
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 t
Mark Dilger writes:
>> On Jan 28, 2020, at 9:30 AM, Tom Lane wrote:
>> A brute-force answer, if there are few enough cases, is to recognize
>> them regardless of the specific value of LC_TIME. Do we think
>> anybody would notice or care if to_date('Sonnabend', 'TMDay') works
>> even when in a no
> On Jan 28, 2020, at 9:30 AM, Tom Lane wrote:
>
> A brute-force answer, if there are few enough cases, is to recognize
> them regardless of the specific value of LC_TIME. Do we think
> anybody would notice or care if to_date('Sonnabend', 'TMDay') works
> even when in a non-German locale?
I
Mark Dilger writes:
> But then the manual page goes on to say:
>> %E* %O*
>> POSIX locale extensions. The sequences %Ec %EC %Ex %EX %Ey %EY %Od %Oe %OH
>> %OI %Om %OM %OS %Ou %OU %OV %Ow %OW %Oy are supposed to provide alternate
>> representations.
>>
>> Additionally %OB implemented to repres
On 2020-Jan-28, Peter Eisentraut wrote:
> On 2020-01-28 04:05, Mark Dilger wrote:
> > German uses both Sonnabend and Samstag for Saturday, so don’t you have to
> > compare to a list of values anyway?
>
> Yeah, good point. If it doesn't accept both "Sonnabend" and "Samstag", then
> it's not real
> On Jan 28, 2020, at 7:47 AM, Juan José Santamaría Flecha
> wrote:
>
> This looks like a POSIX feature that some systems might not like (Windows
> [1]). But if this is something that the patch should aim to, I am fine with a
> RWF and give it another try in the future.
As long as this imp
On Tue, Jan 28, 2020 at 4:06 PM Mark Dilger
wrote:
>
> I’m not insisting, just asking about the design. If it only works with
> one name supported per weekday per language, and per month per language,
> I’m not going to object. I was just curious if you were going to support
> multiple names an
> On Jan 28, 2020, at 6:51 AM, Tom Lane wrote:
>
> Peter Eisentraut writes:
>> On 2020-01-28 04:05, Mark Dilger wrote:
>>> German uses both Sonnabend and Samstag for Saturday, so don’t you have to
>>> compare to a list of values anyway?
>
>> Yeah, good point. If it doesn't accept both "Son
Peter Eisentraut writes:
> On 2020-01-28 04:05, Mark Dilger wrote:
>> German uses both Sonnabend and Samstag for Saturday, so don’t you have to
>> compare to a list of values anyway?
> Yeah, good point. If it doesn't accept both "Sonnabend" and "Samstag",
> then it's not really usable.
If we'
On 2020-01-28 03:11, Tom Lane wrote:
The other question your example raises is whether we should be trying
to de-accent before comparison, ie was it right for 'Ιανουάριος' to
be treated differently from 'Ιανουαριος'. I don't know enough Greek
to say, but it kind of feels like that should be outs
On 2020-01-28 04:05, Mark Dilger wrote:
German uses both Sonnabend and Samstag for Saturday, so don’t you have to
compare to a list of values anyway?
Yeah, good point. If it doesn't accept both "Sonnabend" and "Samstag",
then it's not really usable.
--
Peter Eisentraut http://
> On Jan 27, 2020, at 6:11 PM, Tom Lane wrote:
>
> and I think it
> makes German better (does 'ß' appear in any month/day names there?),
> so maybe we should just roll with that.
To my knowledge, neither /ß/ nor /ss/ occur in day or month names in German,
neither presently nor in recent tim
Peter Eisentraut writes:
> For the record, the correct form of that would appear to be
> select to_date('Ιανουάριος', 'TMMonth');
> with the accent. I had tried different variations of that and they all
> failed.
OK, so for anyone who is as confused as I was, the main point here
seems to be thi
On 2020-01-24 19:01, Peter Eisentraut wrote:
postgres=# select to_char(now(),'TMmonth');
to_char
ιανουαρίου
(1 row)
which is the genitive of ιανουάριος. You use the genitive form for a
date (24th of January) but the nominative otherwise. But the reverse
mapping can only tak
On 2020-01-24 18:25, Juan José Santamaría Flecha wrote:
To illustrate the issue, it does not work as expected:
postgres=# select lower(to_char(now(),'TMMONTH'));
lower
ιανουάριοσ
(1 row)
postgres=# select to_char(now(),'TMmonth');
to_char
ιανουάριος
(1 row)
On Fri, Jan 24, 2020 at 5:46 PM Tom Lane wrote:
> Peter Eisentraut writes:
> > Looking through the patch quickly, if you want to get Unicode-fancy,
> > doing a case-insensitive comparison by running lower-case on both
> > strings is also wrong in corner cases. All the Greek month names end in
>
Peter Eisentraut writes:
> Looking through the patch quickly, if you want to get Unicode-fancy,
> doing a case-insensitive comparison by running lower-case on both
> strings is also wrong in corner cases. All the Greek month names end in
> sigma, so I suspect that this patch might not work cor
On 2020-01-24 17:22, Tom Lane wrote:
Alvaro Herrera writes:
But that's a different POV. The input to this function could come from
arbitrary user input from any application whatsoever. So the only
reason we can get away with that is because the example regression case
Juan José added (which u
Alvaro Herrera writes:
> But that's a different POV. The input to this function could come from
> arbitrary user input from any application whatsoever. So the only
> reason we can get away with that is because the example regression case
> Juan José added (which uses non-normals) does not confor
On 2020-Jan-24, Peter Eisentraut wrote:
> When you interact with glibc locale functions, you essentially have to
> assume that everything is in NFC. When using ICU locale functions (which we
> don't here, but just for the sake of argument), then I would expect that ICU
> does appropriate normaliz
On 2020-01-24 12:44, Alvaro Herrera wrote:
On 2020-Jan-24, Juan José Santamaría Flecha wrote:
There is an open patch that will make the normalization functionality user
visible [1]. So, if a user can call to_date(normalize('01 ŞUB 2010'), 'DD
TMMON ') I would vote to drop the normalization
=?UTF-8?Q?Juan_Jos=C3=A9_Santamar=C3=ADa_Flecha?=
writes:
> On Thu, Jan 23, 2020 at 11:00 PM Tom Lane wrote:
>> * It's not exactly apparent to me why this code should be concerned
>> about non-normalized characters when noplace else in the backend is.
> There is an open patch that will make the
On 2020-Jan-24, Juan José Santamaría Flecha wrote:
> There is an open patch that will make the normalization functionality user
> visible [1]. So, if a user can call to_date(normalize('01 ŞUB 2010'), 'DD
> TMMON ') I would vote to drop the normalization logic inside this patch
> altogether.
I
On Thu, Jan 23, 2020 at 11:00 PM Tom Lane wrote:
Thank you for your time looking into this.
Here's a v7 patch, rebased over my recent hacking, and addressing
> most of the complaints I raised in <31691.1579648...@sss.pgh.pa.us>.
> However, I've got some new complaints now that I've looked harder
Here's a v7 patch, rebased over my recent hacking, and addressing
most of the complaints I raised in <31691.1579648...@sss.pgh.pa.us>.
However, I've got some new complaints now that I've looked harder
at the code:
* It's not exactly apparent to me why this code should be concerned
about non-normal
Alvaro Herrera writes:
> Even whitespace is problematic for some languages, such as Afan,
> mon "Qunxa Garablu";/
> "Naharsi Kudo";/
> "Ciggilta Kudo";/
> (etc) but I think whitespace-splitting is going to be more comprehensible
> in the vast majority of cases, even if not
On 2020-Jan-23, Tom Lane wrote:
> That particular case could be improved by stopping at a dash ... but
> since this code is also used to match strings like "A.M.", we can't
> just exclude punctuation in general. Breaking at whitespace seems
> like a reasonable compromise.
Yeah, and there are cas
Alvaro Herrera writes:
> On 2020-Jan-22, Tom Lane wrote:
>> Arthur Zakirov writes:
>>> Shouldn't we just show all remaining string instead of truncating it?
>> That would avoid a bunch of arbitrary decisions, for sure.
>> Anybody have an objection?
> I think it would be clearer to search for w
On 2020-Jan-22, Tom Lane wrote:
> Arthur Zakirov writes:
> > 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 th
Arthur Zakirov writes:
> 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
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 b
I wrote:
> One thing I completely don't understand is why it's sufficient for
> seq_search_localized to do "initcap" semantics. Shouldn't it cover
> the all-upper and all-lower cases as well, as the existing seq_search
> code does? (That is, why is it okay to ignore the "type" argument?)
I took
=?UTF-8?Q?Juan_Jos=C3=A9_Santamar=C3=ADa_Flecha?=
writes:
> [ 0001-Allow-localized-month-names-to_date-v6.patch ]
I took a quick look through this.
One thing I completely don't understand is why it's sufficient for
seq_search_localized to do "initcap" semantics. Shouldn't it cover
the all-uppe
On Wed, Jan 15, 2020 at 11:20 AM Arthur Zakirov wrote:
>
> I have some couple picky notes.
>
>
Thanks for the review.
> > + 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_
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 allocate
On Sat, Jan 11, 2020 at 5:06 PM Tomas Vondra
wrote:
>
> Thanks. I did a quick review of this patch, and I think it's almost RFC.
>
>
Thanks for reviewing.
> - In func.sgml, it seems we've lost this bit:
>
>
> TM does not include trailing blanks.
> to_timestamp and to_dat
On Thu, Sep 26, 2019 at 08:36:25PM +0200, Juan José Santamaría Flecha wrote:
On Wed, Sep 25, 2019 at 9:57 PM Alvaro Herrera wrote:
This patch no longer applies. Can you please rebase?
Thank you for the notification.
The patch rot after commit 1a950f3, a rebased version is attached.
Than
On Wed, Sep 25, 2019 at 9:57 PM Alvaro Herrera wrote:
>
> This patch no longer applies. Can you please rebase?
Thank you for the notification.
The patch rot after commit 1a950f3, a rebased version is attached.
Regards,
Juan José Santamaría Flecha
diff --git a/doc/src/sgml/func.sgml b/doc/src/
This patch no longer applies. Can you please rebase?
--
Álvaro Herrerahttps://www.2ndQuadrant.com/
PostgreSQL Development, 24x7 Support, Remote DBA, Training & Services
On Wed, Sep 18, 2019 at 11:09 AM Juan José Santamaría Flecha
wrote:
>
> On Fri, Sep 13, 2019 at 10:31 PM Alvaro Herrera
> wrote:
> >
> Thanks for taking a look at this.
>
> > I'm confused why we acquire the MONTH_DIM / etc definitions. Can't we
> > just use lengthof() of the corresponding array?
On Fri, Sep 13, 2019 at 10:31 PM Alvaro Herrera
wrote:
>
Thanks for taking a look at this.
> I'm confused why we acquire the MONTH_DIM / etc definitions. Can't we
> just use lengthof() of the corresponding array? AFAICS it should work
> just as well.
>
It was because of the length difference b
On 2019-Aug-22, Juan José Santamaría Flecha wrote:
> On Sun, Aug 18, 2019 at 10:42 AM Juan José Santamaría Flecha
> wrote:
> >
> > Going through the current items in the wiki's todo list, I have been
> > looking into: "Allow to_date () and to_timestamp () to accept
> > localized month names".
>
On Thu, Aug 22, 2019 at 9:38 PM Juan José Santamaría Flecha
wrote:
>
> >
> > Going through the current items in the wiki's todo list, I have been
> > looking into: "Allow to_date () and to_timestamp () to accept
> > localized month names".
> >
>
> I have gone through a second take on this, trying
On Sun, Aug 18, 2019 at 10:42 AM Juan José Santamaría Flecha
wrote:
>
> Going through the current items in the wiki's todo list, I have been
> looking into: "Allow to_date () and to_timestamp () to accept
> localized month names".
>
I have gone through a second take on this, trying to give it a b
Hello,
Going through the current items in the wiki's todo list, I have been
looking into: "Allow to_date () and to_timestamp () to accept
localized month names".
It seems to me that the code is almost there, so I would like to know
if something like the attached patch would be a reasonable way to
64 matches
Mail list logo
