Re: Incorrect processing of CREATE TRANSFORM with DDL deparding
От | Michael Paquier |
---|---|
Тема | Re: Incorrect processing of CREATE TRANSFORM with DDL deparding |
Дата | |
Msg-id | CAB7nPqR3oeggsoVqKrgvoS=mJCfH1qMbFHjCGj2RVLu0Nf7Sjg@mail.gmail.com обсуждение исходный текст |
Ответ на | Re: Incorrect processing of CREATE TRANSFORM with DDL deparding (Alvaro Herrera <alvherre@2ndquadrant.com>) |
Ответы |
Re: Incorrect processing of CREATE TRANSFORM with DDL deparding
Re: Incorrect processing of CREATE TRANSFORM with DDL deparding |
Список | pgsql-bugs |
On Tue, May 26, 2015 at 12:52 AM, Alvaro Herrera wrote: > Michael Paquier wrote: >> In ProcessUtilitySlow()@utility.c, for a node T_CreateTransformStmt, >> process does not return ObjectAddress. This makes process inconsistent >> with the other commands and the ObjectAddress passed to >> EventTriggerCollectSimpleCommand is not initialized. >> Coverity has pointed out the error, I just some legwork to sort out a fix. > > Yeah, I had noticed this and was pretty annoyed because we ended up in > precisely the situation we didn't want to be: new code is added to > ProcessUtility that is not handled by the deparse framework. (I > don't know whether TRANSFORM went in first or deparse, but it doesn't > really matter.) > > The fix as you say is pretty trivial, but I would like to use this is a > test case to ensure that we will catch all these mistakes in the future > too not only this particular one. I guess that you could add an assertion at the bottom of ProcessUtilitySlow() as well to check code paths where ObjectAddress is not initialized correctly. -- Michael
В списке pgsql-bugs по дате отправления: