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.
> >> * 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.
> 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.
In response to
pgsql-hackers by date
|Next:||From: Magnus Hagander||Date: 2011-10-31 18:08:16|
|Subject: Re: Your review of pg_receivexlog/pg_basebackup|
|Previous:||From: Merlin Moncure||Date: 2011-10-31 17:53:10|
|Subject: Re: Multiple queries in transit|