Oliver Ford writes:
> [ 0001-apply-number-v3.patch ]
I looked at this patch briefly and have a couple of comments:
* It seems entirely wrong to be matching to L_thousands_sep in the
NUM_COMMA case; that format code is by definition not locale aware,
so it should be matching to plain ',' independ
> On 25 Sep 2017, at 02:52, Nathan Wagner wrote:
>
> On Thu, Aug 17, 2017 at 12:33:02PM +0100, Oliver Ford wrote:
>
>> Ok I've made that change in the attached v3. I'm not sure as I'm on
>> en_US.UTF-8 locale too. Maybe something Windows specific?
>
> This patch applies against master (8485a25a
On Mon, Sep 25, 2017 at 07:52:19PM +0100, Oliver Ford wrote:
> Thanks for your review. The issue is that Oracle throws errors on many
> more input cases than Postgres does, so making it exactly like Oracle
> could break a lot of existing users. E.g. to_number ('123,000', '999')
> returns '123' on
On Monday, 25 September 2017, Nathan Wagner wrote:
> On Thu, Aug 17, 2017 at 12:33:02PM +0100, Oliver Ford wrote:
>
> > Ok I've made that change in the attached v3. I'm not sure as I'm on
> > en_US.UTF-8 locale too. Maybe something Windows specific?
>
> This patch applies against master (8485a25a
On Thu, Aug 17, 2017 at 12:33:02PM +0100, Oliver Ford wrote:
> Ok I've made that change in the attached v3. I'm not sure as I'm on
> en_US.UTF-8 locale too. Maybe something Windows specific?
This patch applies against master (8485a25a), compiles, and
passes a make check.
I tested both on my mac
On Thu, Aug 17, 2017 at 11:55 AM, Thomas Munro
wrote:
> Hmm. Just in case my macOS laptop (CC=Apple's clang,
> LANG=en_NZ.UTF-8) was unduly affected by cosmic rays I tried on a
> couple of nearby servers running FreeBSD 11.1 (CC=clang, LANG=)
> and CentOS 7.3 (CC=gcc, LANG=en_US.utf-8) and got t
On Thu, Aug 17, 2017 at 9:48 PM, Oliver Ford wrote:
>> The tests you added pass for me but the int8 test now fails with the
>> following (this is from regression.diff after running
>> 'PG_REGRESS_DIFF_OPTS="-dU10" make check'). It looks like some new
>> whitespace is appearing on the right in the
> The tests you added pass for me but the int8 test now fails with the
> following (this is from regression.diff after running
> 'PG_REGRESS_DIFF_OPTS="-dU10" make check'). It looks like some new
> whitespace is appearing on the right in the output of to_char(). I
> didn't try to understand why.
On Thu, Aug 10, 2017 at 10:21 PM, Oliver Ford wrote:
> Prevents an issue where numbers can be skipped in the to_number()
> function when the format mask contains a "G" or a "," but the input
> string doesn't contain a separator. This resolves the TODO item "Fix
> to_number() handling for values no
Prevents an issue where numbers can be skipped in the to_number()
function when the format mask contains a "G" or a "," but the input
string doesn't contain a separator. This resolves the TODO item "Fix
to_number() handling for values not matching the format string".
== Change ==
Currently, if th
10 matches
Mail list logo
