Re: Tom Lane
> Christoph Berg writes:
> > A possible solution might be to rip out all the locale columns except
> > "Encoding" from \l, and leave them in place for \l+.
>
> I'd rather see a single column summarizing the locale situation.
> Perhaps it could be COALESCE(daticulocale, datcollate),
Christoph Berg writes:
> A possible solution might be to rip out all the locale columns except
> "Encoding" from \l, and leave them in place for \l+.
I'd rather see a single column summarizing the locale situation.
Perhaps it could be COALESCE(daticulocale, datcollate), or
something using a CASE
Re: Peter Eisentraut
> > Since the intended usage seems to be that databases should either be
> > using libc, or the ICU locales, but probably not both at the same
> > time, does it make sense to clutter the already very wide `psql -l`
> > output with two new extra columns?
>
> Good point, let me
Hi,
On 2022-03-20 11:03:38 +0100, Peter Eisentraut wrote:
> committed
Thanks. Rebasing over that fixed the meson Centos 7 build in my meson
tree. https://cirrus-ci.com/build/5265480968568832
Greetings,
Andres Freund
On Sun, Mar 20, 2022 at 11:03:38AM +0100, Peter Eisentraut wrote:
> On 19.03.22 05:14, Julien Rouhaud wrote:
> > On Fri, Mar 18, 2022 at 03:09:59PM -0700, Andres Freund wrote:
> > > Hi,
> > >
> > > On 2022-03-18 20:28:58 +0100, Peter Eisentraut wrote:
> > > > Why does your patch introduce a
On 19.03.22 18:53, Christoph Berg wrote:
Re: Peter Eisentraut
Since some (legacy) code still uses the libc locale facilities
directly, we still need to set the libc global locale settings even if
ICU is otherwise selected. So pg_database now has three
locale-related fields: the existing
On 19.03.22 05:14, Julien Rouhaud wrote:
On Fri, Mar 18, 2022 at 03:09:59PM -0700, Andres Freund wrote:
Hi,
On 2022-03-18 20:28:58 +0100, Peter Eisentraut wrote:
Why does your patch introduce a function check_icu_locale() that is only
called once? Did you have further plans for that?
I
Re: Peter Eisentraut
> Since some (legacy) code still uses the libc locale facilities
> directly, we still need to set the libc global locale settings even if
> ICU is otherwise selected. So pg_database now has three
> locale-related fields: the existing datcollate and datctype, which are
>
On Fri, Mar 18, 2022 at 03:09:59PM -0700, Andres Freund wrote:
> Hi,
>
> On 2022-03-18 20:28:58 +0100, Peter Eisentraut wrote:
> > Why does your patch introduce a function check_icu_locale() that is only
> > called once? Did you have further plans for that?
>
> I like that it moves ICU code out
On Fri, Mar 18, 2022 at 04:04:10PM -0400, Tom Lane wrote:
> Peter Eisentraut writes:
> > Another option is that we just don't do the check in initdb. As the
> > tests show, you will then get an error from the backend call, so it's
> > really just a question of when the error is reported.
>
> +1
Hi,
On 2022-03-18 20:28:58 +0100, Peter Eisentraut wrote:
> Why does your patch introduce a function check_icu_locale() that is only
> called once? Did you have further plans for that?
I like that it moves ICU code out of dbcommands.c - imo there should be few
calls to ICU functions outside of
Peter Eisentraut writes:
> Another option is that we just don't do the check in initdb. As the
> tests show, you will then get an error from the backend call, so it's
> really just a question of when the error is reported.
+1 ... seems better to not have two copies of the code.
On 18.03.22 10:27, Julien Rouhaud wrote:
I'm attaching a patch that fixes both issues for me with ICU 50. Note that
there's already a test that would have failed for CREATE DATABASE if initdb
tests didn't fail first, so no new test needed.
I ended up copy/pasting icu_set_collation_attributes()
(moving to -hackers)
On Fri, Mar 18, 2022 at 03:40:51PM +0800, Julien Rouhaud wrote:
> On Fri, Mar 18, 2022 at 02:36:48PM +0800, Julien Rouhaud wrote:
> > On Fri, Mar 18, 2022 at 06:15:47PM +1300, Thomas Munro wrote:
> > >
> > > No idea what's happening here but one observation is that that
14 matches
Mail list logo
