On Mon, 2011-10-24 at 13:15 +0300, Heikki Linnakangas wrote:
> >> * range_constructor_internal - I think it would be better to move logic
> >> to figure out the the arguments into the callers.
> >
> > Done.
>
> The comment above range_constructor0() is now outdated.
Removed.
> >> * The gist support functions frequently call range_deserialize(), which
> >> does catalog lookups. Isn't that horrendously expensive?
> >
> > Yes, it was. I have introduced a cached structure that avoids syscache
> > lookups when it's the same range as the last lookup (the common case).
>
> Hmm, I don't think that's safe. After Oid wraparound, a range type oid
> might get reused for some other range type, and the cache would return
> stale values. Extremely unlikely to happen by accident, but could be
> exploited by an attacker.
Done.
> Ok. The name "canonical" certainly hints at that, but it would be good
> to explicitly state that guideline. As the text stands, it would seem
> that a canonical function that maps "[1,7]" to "[1,8)", and also vice
> versa, "[1,8)" to "[1,7]", would be valid. That would be pretty silly,
> but it would be good to say something like "The canonical output for two
> values that are equal, like [1,7] and [1,8), must be equal. It doesn't
> matter which representation you choose to be the canonical one, as long
> as two equal values with different formattings are always mapped to the
> same value with same formatting"
Used your wording, thank you.
Regards,
Jeff Davis