On Fri, Feb 14, 2014 at 05:02:26PM -0500, Bruce Momjian wrote:
On Thu, Feb 13, 2014 at 09:47:01PM -0500, Bruce Momjian wrote:
On Wed, Oct 16, 2013 at 02:17:11PM -0400, Bruce Momjian wrote:
You can see the UTF8 case is fine because \n is considered greater
than space, but in the C
On Thu, Feb 13, 2014 at 09:47:01PM -0500, Bruce Momjian wrote:
On Wed, Oct 16, 2013 at 02:17:11PM -0400, Bruce Momjian wrote:
You can see the UTF8 case is fine because \n is considered greater
than space, but in the C locale, where \n is less than space, the
false return value shows
On Wed, Oct 16, 2013 at 02:17:11PM -0400, Bruce Momjian wrote:
You can see the UTF8 case is fine because \n is considered greater
than space, but in the C locale, where \n is less than space, the
false return value shows the problem with
internal_bpchar_pattern_compare() trimming the
You can see the UTF8 case is fine because \n is considered greater
than space, but in the C locale, where \n is less than space, the
false return value shows the problem with
internal_bpchar_pattern_compare() trimming the string and first
comparing on lengths. This is exactly the
On Fri, Oct 11, 2013 at 3:44 PM, Bruce Momjian br...@momjian.us wrote:
You have some good questions here, though there are two interrelated
things going on here. First is collation, and the second is the
trimming of spaces from char() comparisons.
Sorry, I should have probably mentioned more
On Sun, Sep 22, 2013 at 08:51:26PM -0400, Thomas Fanghaenel wrote:
I was wondering about the proper semantics of CHAR comparisons in some corner
cases that involve control characters with values that are less than 0x20
(space).
Consider the following testcase:
===
create table t (a int,
Bruce Momjian br...@momjian.us wrote:
Thomas Fanghaenel wrote:
I was wondering about the proper semantics of CHAR comparisons in some corner
cases that involve control characters with values that are less than 0x20
(space).
What matters in general isn't where the characters fall when
