Re: Range Types - typo + NULL string constructor - Mailing list pgsql-hackers

From Jeff Janes
Subject Re: Range Types - typo + NULL string constructor
Date
Msg-id CAMkU=1zqxSh+KrSEmnxCxzveza_uBbbsgALsR5Ngy85DFuZqog@mail.gmail.com
Whole thread Raw
In response to Re: Range Types - typo + NULL string constructor  (Jeff Davis <pgsql@j-davis.com>)
Responses Re: Range Types - typo + NULL string constructor
List pgsql-hackers
On Sun, Oct 2, 2011 at 12:05 PM, Jeff Davis <pgsql@j-davis.com> wrote:
> On Sun, 2011-10-02 at 11:32 +0200, Florian Pflug wrote:
>> Looking at the patch, I noticed that it's possible to specify the default
>> boundaries ([], [), (] or ()) per individual float type with the
>> DEFAULT_FLAGS clause of CREATE TYPE .. AS RANGE. I wonder if that doesn't
>> do more harm then good - it makes it impossible to deduce the meaning of
>> e.g. numericrange(1.0, 2.0) without looking up the definition of numericrange.
>>
>> I suggest we pick one set of default boundaries, ideally '[)' since that
>> is what all the built-in canonization functions produce, and stick with it.
>
> Done.
>
> Also, made the range parsing even more like records with more code
> copied verbatim. And fixed some parsing tests along the way.

When I apply this to head, "make check" fails with:
 create type textrange_en_us as range(subtype=text, collation="en_US");
+ ERROR:  collation "en_US" for encoding "SQL_ASCII" does not exist

Is this a problem?  e.g. will it break the build-farm?

"make check LANG=en_US" does pass

Cheers,

Jeff


pgsql-hackers by date:

Previous
From: Robert Haas
Date:
Subject: Re: index-only scans
Next
From: Jeff Davis
Date:
Subject: Re: Range Types - typo + NULL string constructor