Re: pg_partition_tree crashes for a non-defined relation
Вложения
В списке pgsql-hackers по дате отправления:
| От | Michael Paquier |
|---|---|
| Тема | Re: pg_partition_tree crashes for a non-defined relation |
| Дата | |
| Msg-id | 20181209223941.GA3710@paquier.xyz обсуждение |
| Ответ на | Re: pg_partition_tree crashes for a non-defined relation (Tom Lane <tgl@sss.pgh.pa.us>) |
| Ответы |
Re: pg_partition_tree crashes for a non-defined relation
|
| Список | pgsql-hackers |
On Sun, Dec 09, 2018 at 02:07:29PM -0500, Tom Lane wrote: > Stephen Frost <sfrost@snowman.net> writes: >> I don't entirely buy off on the argument that it's code that's 'highly >> unlikely to break once written' though- we do add new relkinds from time >> to time, for example. Perhaps we could have these functions run just >> once per relkind. > > Well, the relevant code is likely to be "if relkind is not x, y, or z, > then PG_RETURN_NULL". If we add a new relkind and forget to consider the > function, the outcome is a NULL result that perhaps should not have been > NULL ... but a test like this won't help us notice that. Yes, in order to prevent problems with newly-introduced relkinds, I think that the checks within functions should be careful to check only for relkinds that they support, and not list those they do not support. -- Michael
В списке pgsql-hackers по дате отправления:
Сайт использует файлы cookie для корректной работы и повышения удобства. Нажимая кнопку «Принять» или продолжая пользоваться сайтом, вы соглашаетесь на их использование в соответствии с Политикой в отношении обработки cookie ООО «ППГ», в том числе на передачу данных из файлов cookie сторонним статистическим и рекламным службам. Вы можете управлять настройками cookie через параметры вашего браузера