From: | Florian Pflug <fgp(at)phlo(dot)org> |
---|---|
To: | Jeff Davis <pgsql(at)j-davis(dot)com> |
Cc: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>, Merlin Moncure <mmoncure(at)gmail(dot)com>, pgsql-hackers(at)postgresql(dot)org |
Subject: | Re: Range Types and extensions |
Date: | 2011-06-09 22:26:30 |
Message-ID: | BF45665B-D5C9-4E9F-88A6-0E7FABF4550F@phlo.org |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
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
From | Date | Subject | |
---|---|---|---|
Next Message | Greg Smith | 2011-06-09 22:29:36 | Re: tuning autovacuum |
Previous Message | MauMau | 2011-06-09 22:18:44 | Re: Fw: [BUGS] BUG #6011: Some extra messages are output in the event log at PostgreSQL startup |