Re: Table AM Interface Enhancements
От | Tom Lane |
---|---|
Тема | Re: Table AM Interface Enhancements |
Дата | |
Msg-id | 1092843.1711989403@sss.pgh.pa.us обсуждение исходный текст |
Ответ на | Re: Table AM Interface Enhancements (Andrei Lepikhov <a.lepikhov@postgrespro.ru>) |
Ответы |
Re: Table AM Interface Enhancements
Re: Table AM Interface Enhancements |
Список | pgsql-hackers |
Coverity complained about what you did in RelationParseRelOptions in c95c25f9a: *** CID 1595992: Null pointer dereferences (FORWARD_NULL) /srv/coverity/git/pgsql-git/postgresql/src/backend/utils/cache/relcache.c: 499 in RelationParseRelOptions() 493 494 /* 495 * Fetch reloptions from tuple; have to use a hardwired descriptor because 496 * we might not have any other for pg_class yet (consider executing this 497 * code for pg_class itself) 498 */ >>> CID 1595992: Null pointer dereferences (FORWARD_NULL) >>> Passing null pointer "tableam" to "extractRelOptions", which dereferences it. 499 options = extractRelOptions(tuple, GetPgClassDescriptor(), 500 tableam, amoptsfn); 501 I see that extractRelOptions only uses the tableam argument for some relkinds, and RelationParseRelOptions does set it up for those relkinds --- but Coverity's complaint isn't without merit, because those two switch statements are looking at *different copies of the relkind*, which in theory could be different. This all seems quite messy and poorly factored. Can't we do better? Why do we need to involve two copies of allegedly the same pg_class tuple, anyhow? regards, tom lane
В списке pgsql-hackers по дате отправления: