Re: Range Types - typo + NULL string constructor
От | Jeff Davis |
---|---|
Тема | Re: Range Types - typo + NULL string constructor |
Дата | |
Msg-id | 1320084104.4647.15.camel@jdavis обсуждение исходный текст |
Ответ на | Re: Range Types - typo + NULL string constructor (Heikki Linnakangas <heikki.linnakangas@enterprisedb.com>) |
Список | pgsql-hackers |
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
Вложения
В списке pgsql-hackers по дате отправления: