On 20/04/15 10:29, Tom Lane wrote:
> Yves Dorfsman <yves@zioup.com> writes:
>> What about functions that are simpler such as upper()/lower()?
> If you think those are simpler, you're much mistaken :-(. For instance,
> "lower(first_name) = 'yves'" would have to be translated to something
> like "first_name IN ('yves', 'yveS', 'yvEs', 'yvES', ..., 'YVES')"
> -- 16 possibilities altogether, or 2^N for an N-character string.
> (And that's just assuming ASCII up/down-casing, never mind the interesting
> rules in some non-English languages.) In a case-sensitive index, those
> various strings aren't going to sort consecutively, so we'd end up needing
> a separate index probe for each possibility.
>
> extract(year from date) agrees with timestamp comparison up to boundary
> cases, that is a few hours either way at a year boundary depending on the
> timezone situation. So you could translate it to a lossy-but-indexable
> timestamp comparison condition and not expect to scan too many index items
> that don't satisfy the original extract() condition. But I don't see how
> to make something like that work for mapping case-insensitive searches
> onto case-sensitive indexes.
>
> regards, tom lane
>
>
Yeah, an event that happened at 2 am Thursday January 1st 2015 in New
Zealand, will be in the year 2014 for people of London in England!
Cheers,
Gavin