On Tue, Apr 15, 2025 at 04:08:55PM -0700, Jeff Davis wrote:
> On Mon, 2025-04-14 at 13:44 -0700, Noah Misch wrote:
> > However, I think v17's
> > concept of separate PG_REGEX_ symbols for the default-locale case is
> > still the
> > right thing for v18. In other words, this code should change to l
On Mon, 2025-04-14 at 13:44 -0700, Noah Misch wrote:
> v18 regc_pg_locale.c uses only the locale_t-extended forms, and it
> aims not to
> depend on LC_CTYPE. v17 used both tolower() and tolower_l(), but v18
> uses the
> latter only.
Fixed in v2-0001 by rewording the comment slightly.
>
> Howeve
On Mon, Apr 14, 2025 at 12:59:50PM -0700, Jeff Davis wrote:
> On Sat, 2025-04-12 at 05:34 -0700, Noah Misch wrote:
> > I think the code for (2) and for "I/i in Turkish" haven't returned.
> > Given
> > commit e3fa2b0 restored the v17 "I/i in Turkish" treatment for plain
> > lower(),
> > the regex c
On Sat, 2025-04-12 at 05:34 -0700, Noah Misch wrote:
> I think the code for (2) and for "I/i in Turkish" haven't returned.
> Given
> commit e3fa2b0 restored the v17 "I/i in Turkish" treatment for plain
> lower(),
> the regex code likely needs a similar restoration. If not, the regex
> comments
>
On Mon, Dec 02, 2024 at 10:24:07PM -0800, Jeff Davis wrote:
> On Mon, 2024-12-02 at 17:25 -0500, Tom Lane wrote:
> > > Should I put the special case back?
> >
> > I think so.
>
> Done. I put the special case back in (commit e3fa2b037c) because the
> earlier commit wasn't intended to be a behavio
On Wed, 2024-12-04 at 12:21 -0500, Tom Lane wrote:
> Peter Eisentraut writes:
> > On 02.12.24 23:25, Tom Lane wrote:
> > > Well, also for compatibility with our SQL parser's understanding
> > > of identifier lowercasing.
>
> > Maybe that was relevant before the "name" type got its own
> > collati
Peter Eisentraut writes:
> On 02.12.24 23:25, Tom Lane wrote:
>> Well, also for compatibility with our SQL parser's understanding
>> of identifier lowercasing.
> Maybe that was relevant before the "name" type got its own collation?
downcase_identifier doesn't give a fig about name's collation.
On 02.12.24 23:25, Tom Lane wrote:
Jeff Davis writes:
The behavior is commented (commit 176d5bae1d) in formatting.c:
* ... When using the default
* collation, we apply the traditional Postgres behavior that
* forces ASCII-style treatment of I/i, but in non-default
* collatio
Jeff Davis writes:
> On Mon, 2024-12-02 at 17:25 -0500, Tom Lane wrote:
>> Well, also for compatibility with our SQL parser's understanding
>> of identifier lowercasing.
> But why only for single-byte encodings? And why not for ICU?
I think the not-for-utf8 exclusion was mostly because that was
On Mon, 2024-12-02 at 17:25 -0500, Tom Lane wrote:
> Well, also for compatibility with our SQL parser's understanding
> of identifier lowercasing.
But why only for single-byte encodings? And why not for ICU?
> > Should I put the special case back?
>
> I think so.
Done. I put the special case ba
Jeff Davis writes:
> The behavior is commented (commit 176d5bae1d) in formatting.c:
>* ... When using the default
>* collation, we apply the traditional Postgres behavior that
>* forces ASCII-style treatment of I/i, but in non-default
>* collations you get exactly what the collat
11 matches
Mail list logo
