Re: [GENERAL] Not able to create collation on Windows

Tom Lane <tgl@sss.pgh.pa.us>

From: Tom Lane <tgl@sss.pgh.pa.us>

To: Peter Eisentraut <peter.eisentraut@2ndquadrant.com>

Cc: Murtuza Zabuawala <murtuza.zabuawala@enterprisedb.com>, PostgreSQL mailing lists <pgsql-general@postgresql.org>, pgsql-hackers@postgresql.org

Date: 2017-08-01T15:39:43Z

Lists: pgsql-hackers

Commits

Same data as JSON: GET /api/v1/messages/:b64id/commits the thread's linked commits as JSON, with link sources. API reference →

Revert test case added by commit 1e165d05fe06a9072867607886f818bc255507db.
- 32ca22b02da9 10.0 landed
Second try at getting useful errors out of newlocale/_create_locale.
- 514f6132935d 10.0 landed
Try to deliver a sane message for _create_locale() failure on Windows.
- 1e165d05fe06 10.0 landed
Allow creation of C/POSIX collations without depending on libc behavior.
- f97256570f45 10.0 landed

Peter Eisentraut <peter.eisentraut@2ndquadrant.com> writes:
> On 8/1/17 10:53, Tom Lane wrote:
>> I think this is actually a bug, because the collations code clearly
>> means to allow clones of the C/POSIX locales --- see eg lc_collate_is_c,

> You seem to say that we should support a "POSIX" locale even on systems
> where the C library does not support that.  I'm not convinced about that.

Uh, we already do.  Note all the regression tests that unconditionally
assume that the POSIX collation works.  Also, I am confused by your
apparent belief that there might somewhere be a version of libc that
fails to provide C-locale-compliant behavior.  Surely nobody would
tolerate a version of strcmp() that fails to act per C spec.

			regards, tom lane