On Jun8, 2011, at 17:46 , Jeff Davis wrote:
> It looks like the type input function may be a problem, because it
> doesn't look like it knows what the collation is yet. In other words,
> PG_GET_COLLATION() is zero for the type input function.
>
> But I need to do a comparison to find out if the range is valid or not.
> For instance:
> '[a, Z)'::textrange
> is valid in "en_US" but not "C".
Maybe that check should just be removed? If one views the range
'[L, U)' as a concise way of expressing "L <= x AND x < U" for some
x, then allowing the case L > U seems quite natural. There won't
be any such x of course, but the range is still valid, just empty.
Actually, thinking for this a bit, I believe this is the only
way text ranges can support collations. If the validity of a range
depends on the collation, then changing the collation after creation
seems weird, since it can make previous valid ranges invalid and
vice versa.
There could be a function RANGE_EMPTY() which people can put into
their CHECK constraints if they don't want such ranges to sneak
into their tables...
best regards,
Florian Pflug
