| От | Peter Eisentraut |
|---|---|
| Тема | Re: Updates of SE-PostgreSQL 8.4devel patches (r1268) |
| Дата | |
| Msg-id | 200812111759.33900.peter_e@gmx.net обсуждение исходный текст |
| Ответ на | Re: Updates of SE-PostgreSQL 8.4devel patches (r1268) (Bruce Momjian <bruce@momjian.us>) |
| Список | pgsql-hackers |
On Thursday 11 December 2008 04:52:51 Bruce Momjian wrote: > > > We do have a per-row HEAP_HASOID bit, so I wonder if we can have a > > > HEAP_HASSEC bit too. Right now the HEAP_HASOID is controlled by the > > > CREATE/ALTER table; > > > > The current patch add HEAP_HASSECURITY bit to t_infomask. :-) > > When it is false, its security field is not available and not allocated. > > Good. This is probably OK, but if you want to save a bit or generalize it, it might be worth considering using the normal null bitmap and nullity everywhere instead of individual HEAP_HASTHISORTHAT bits for every feature. Of course, if we expect that most rows will have no security information, this tradeoff might end up on the wrong side of the equation.
В списке pgsql-hackers по дате отправления:
Сайт использует файлы cookie для корректной работы и повышения удобства. Нажимая кнопку «Принять» или продолжая пользоваться сайтом, вы соглашаетесь на их использование в соответствии с Политикой в отношении обработки cookie ООО «ППГ», в том числе на передачу данных из файлов cookie сторонним статистическим и рекламным службам. Вы можете управлять настройками cookie через параметры вашего браузера