On 12.12.24 19:20, Jeff Davis wrote:
On Mon, 2024-12-09 at 11:11 +0100, Peter Eisentraut wrote:
I have expanded this patch set. The first three patches are the same
as
before. I have added a new patch that gets rid of lowerstr() from
ts_locale.c and replaces it with the standard str_tolower()
On 17.12.24 16:25, Andreas Karlsson wrote:
On 12/13/24 6:07 PM, Jeff Davis wrote:
OK, that's fine with me for this patch series.
Eventually though, I think we should have built-in versions of these
ASCII functions. Even if there's no actual problem, it would more
clearly indicate that we only c
On 12/13/24 6:07 PM, Jeff Davis wrote:
OK, that's fine with me for this patch series.
Eventually though, I think we should have built-in versions of these
ASCII functions. Even if there's no actual problem, it would more
clearly indicate that we only care about ASCII at that particular call
site
On Fri, 2024-12-13 at 07:16 +0100, Peter Eisentraut wrote:
> isdigit() and isspace() in particular are widely used throughout the
> backend code without such concerns. I think the assumption is that
> this
> is not a problem in practice: For multibyte encodings, these
> functions
> would only b
On 12.12.24 19:14, Jeff Davis wrote:
On Mon, 2024-12-02 at 11:57 +0100, Peter Eisentraut wrote:
t_isdigit() and t_isspace() are just used to parse various
configuration
and data files, and surely we don't need support for encoding-
dependent
multibyte support for parsing ASCII digits and ASCII s
On Mon, 2024-12-09 at 11:11 +0100, Peter Eisentraut wrote:
> I have expanded this patch set. The first three patches are the same
> as
> before. I have added a new patch that gets rid of lowerstr() from
> ts_locale.c and replaces it with the standard str_tolower() that
> everyone else is using
On Mon, 2024-12-02 at 11:57 +0100, Peter Eisentraut wrote:
> t_isdigit() and t_isspace() are just used to parse various
> configuration
> and data files, and surely we don't need support for encoding-
> dependent
> multibyte support for parsing ASCII digits and ASCII spaces.
> ... So these can
.
[0]:
https://www.postgresql.org/message-id/flat/2830211e1b6e6a2e26d845780b03e125281ea17b.ca...@j-davis.com
On 02.12.24 11:57, Peter Eisentraut wrote:
Infamously, the tsearch locale support in src/backend/tsearch/
ts_locale.c still depends on libc environment variable locale settings
and is not
Infamously, the tsearch locale support in
src/backend/tsearch/ts_locale.c still depends on libc environment
variable locale settings and is not caught up with pg_locale_t,
collations, ICU, and all that newer stuff. This is used in the tsearch
facilities themselves, but also in other modules
On Sat, Aug 10, 2019 at 11:50 AM Thomas Munro wrote:
> On Fri, Aug 9, 2019 at 6:15 PM Yonatan Misgan wrote:
> > Can I implement it as a locale support? When the user want to change the
> > lc _time = am_ET(Amharic Ethiopia ) the date and time representation of the
> > d
On Fri, Aug 9, 2019 at 6:15 PM Yonatan Misgan wrote:
> Can I implement it as a locale support? When the user want to change the lc
> _time = am_ET(Amharic Ethiopia ) the date and time representation of the
> database systems be in Ethiopian calendar.
Hi Yonatan,
I'm not an
Can I implement it as a locale support? When the user want to change the lc
_time = am_ET(Amharic Ethiopia ) the date and time representation of the
database systems be in Ethiopian calendar.
Original message
From: Thomas Munro
Date: 8/9/19 1:17 AM (GMT+03:00)
To: Peter
On Fri, Aug 9, 2019 at 6:19 AM Peter Geoghegan wrote:
> On Thu, Aug 8, 2019 at 6:29 AM Yonatan Misgan wrote:
> > So my question is after developing the converter function where I put it
> > for accessing it on PostgreSQL.
>
> Maybe you can take some inspiration from the postgresql-unit extensio
On Thu, Aug 8, 2019 at 6:29 AM Yonatan Misgan wrote:
> So my question is after developing the converter function where I put it for
> accessing it on PostgreSQL.
Maybe you can take some inspiration from the postgresql-unit extension:
https://github.com/df7cb/postgresql-unit
Note that it is bu
On 8/8/19 9:29 AM, Yonatan Misgan wrote:
> From: Thomas Munro
>> Perl, Python etc. If I were you I think I'd experiment with a
>> prototype implementation using PL/Perl, PL/Python etc (a way to
As a bit of subtlety that might matter, the internal representation
in PostgreSQL, as in ISO 8601, ap
ction where I put it for
accessing it on PostgreSQL.
Original message
From: Thomas Munro
Date: 8/8/19 11:34 AM (GMT+03:00)
To: Yonatan Misgan
Cc: pgsql-hackers@lists.postgresql.org
Subject: Re: Locale support
On Thu, Aug 8, 2019 at 7:31 PM Yonatan Misgan wrote:
> I am
On Thu, Aug 8, 2019 at 7:31 PM Yonatan Misgan wrote:
> I am Yonathan Misgan from Ethiopia, want to add some functionalities on
> PostgreSQL to support Ethiopian locales. I want your advice where I start to
> hack the PostgresSQL source code. I have attached some synopsis about the
> existing pr
I am Yonathan Misgan from Ethiopia, want to add some functionalities on
PostgreSQL to support Ethiopian locales. I want your advice where I start to
hack the PostgresSQL source code. I have attached some synopsis about the
existing problems of PostgresSQL related with Ethiopian locale specially
18 matches
Mail list logo
