On Thu, Jun 9, 2011 at 6:26 PM, Florian Pflug <f...@phlo.org> wrote: > 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...
I think the collation is going to have to be baked into the type definition, no? You can't just up and change the collation of the column as you could for a straight text column, if that might cause the contents of some rows to be viewed as invalid. -- Robert Haas EnterpriseDB: http://www.enterprisedb.com The Enterprise PostgreSQL Company -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
