Re: Incorrect processing of CREATE TRANSFORM with DDL deparding - Mailing list pgsql-bugs

From Michael Paquier
Subject Re: Incorrect processing of CREATE TRANSFORM with DDL deparding
Date
Msg-id CAB7nPqR3oeggsoVqKrgvoS=mJCfH1qMbFHjCGj2RVLu0Nf7Sjg@mail.gmail.com
Whole thread Raw
In response to Re: Incorrect processing of CREATE TRANSFORM with DDL deparding  (Alvaro Herrera <alvherre@2ndquadrant.com>)
Responses Re: Incorrect processing of CREATE TRANSFORM with DDL deparding  (Michael Paquier <michael.paquier@gmail.com>)
Re: Incorrect processing of CREATE TRANSFORM with DDL deparding  (Stephen Frost <sfrost@snowman.net>)
List 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 by date:

Previous
From: Alvaro Herrera
Date:
Subject: Re: Incorrect processing of CREATE TRANSFORM with DDL deparding
Next
From: Venkata Balaji N
Date:
Subject: Re: BUG #13307: Increasing space