On 3/24/17 22:28, Tom Lane wrote:
> David Rowley writes:
>> I see this commit changed the definition of pg_locale_t
>> but forgot to update varstr_cmp() completely.
>
> It's pretty disturbing that we don't seem to have caught that
> in testing.
Or during
On 3/24/17 20:32, David Rowley wrote:
> but forgot to update varstr_cmp() completely.
>
> result = wcscoll_l((LPWSTR) a1p, (LPWSTR) a2p, mylocale);
>
> should be:
>
> result = wcscoll_l((LPWSTR) a1p, (LPWSTR) a2p, mylocale->info.lt);
>
> Patch attached.
Fixed.
--
Peter Eisentraut
On 3/23/17 23:53, Tom Lane wrote:
> Ah, scratch that, I was overthinking it. The problem is pretty
> clear from the error message:
>
> + ERROR: collation "en-x-icu" for encoding "SQL_ASCII" does not exist
>
> I can reproduce this with vanilla configure options if I'm running
> with --with-icu
David Rowley writes:
> I see this commit changed the definition of pg_locale_t
> but forgot to update varstr_cmp() completely.
It's pretty disturbing that we don't seem to have caught that
in testing. Some work on code coverage seems indicated.
On 24 March 2017 at 06:33, Peter Eisentraut wrote:
> http://git.postgresql.org/pg/commitdiff/eccfef81e1f73ee41f1d8bfe4fa4e80576945048
[...]
> src/include/utils/pg_locale.h| 32 +-
I see this commit changed the definition of pg_locale_t
+struct pg_locale_t
On 03/24/2017 09:26 AM, Tom Lane wrote:
> Andrew Dunstan writes:
>> On 03/23/2017 11:53 PM, Tom Lane wrote:
>>> + ERROR: collation "en-x-icu" for encoding "SQL_ASCII" does not exist
>>>
>>> I can reproduce this with vanilla configure options if I'm running
>>>
Andrew Dunstan writes:
> On 03/23/2017 11:53 PM, Tom Lane wrote:
>> + ERROR: collation "en-x-icu" for encoding "SQL_ASCII" does not exist
>>
>> I can reproduce this with vanilla configure options if I'm running
>> with --with-icu and LANG=C. In short, this
On 03/23/2017 11:53 PM, Tom Lane wrote:
> I wrote:
>> The buildfarm's mostly happy, but "prion" still isn't, which
>> suggests there's someplace in the new code that references an
>> already-closed relcache entry.
> Ah, scratch that, I was overthinking it. The problem is pretty
> clear from the
I wrote:
> The buildfarm's mostly happy, but "prion" still isn't, which
> suggests there's someplace in the new code that references an
> already-closed relcache entry.
Ah, scratch that, I was overthinking it. The problem is pretty
clear from the error message:
+ ERROR: collation "en-x-icu"
The buildfarm's mostly happy, but "prion" still isn't, which
suggests there's someplace in the new code that references an
already-closed relcache entry.
regards, tom lane
--
Sent via pgsql-committers mailing list (pgsql-committers@postgresql.org)
To make changes to
On 03/23/2017 04:07 PM, Peter Eisentraut wrote:
> On 3/23/17 15:33, Peter Eisentraut wrote:
>> ICU support
> Seeing some crashes on the build farm, investigating. If someone can
> reproduce locally and get a backtrace, let me know.
>
The buildfarm actually does that :-)
See for example
On 3/23/17 15:33, Peter Eisentraut wrote:
> ICU support
Seeing some crashes on the build farm, investigating. If someone can
reproduce locally and get a backtrace, let me know.
--
Peter Eisentraut http://www.2ndQuadrant.com/
PostgreSQL Development, 24x7 Support, Remote DBA,
ICU support
Add a column collprovider to pg_collation that determines which library
provides the collation data. The existing choices are default and libc,
and this adds an icu choice, which uses the ICU4C library.
The pg_locale_t type is changed to a union that contains the
provider-specific
13 matches
Mail list logo