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 -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
