Re: BUG #13126: table constraint loses its comment

On 07/08/2015 08:12 AM, Michael Paquier wrote:
> On Tue, Jul 7, 2015 at 6:24 PM, Petr Jelinek <petr(at)2ndquadrant(dot)com> wrote:
>> On 2015-07-04 13:45, Michael Paquier wrote:
>>>
>>> On Fri, Jul 3, 2015 at 11:59 PM, Petr Jelinek wrote:
>>>>
>>>> Well for indexes you don't really need to add the new AT command, as
>>>> IndexStmt has char *idxcomment which it will automatically uses as
>>>> comment
>>>> if not NULL. While I am not huge fan of the idxcomment it doesn't seem
>>>> to
>>>> be easy to remove it in the future and it's what transformTableLikeClause
>>>> uses so it might be good to be consistent with that.
>>>
>>>
>>> Oh, right, I completely missed your point and this field in IndexStmt.
>>> Yes it is better to be consistent in this case and to use it. It makes
>>> as well the code easier to follow.
>>> Btw, regarding the new AT routines, I am getting find of them, it
>>> makes easier to follow which command is added where in the command
>>> queues.
>>>
>>> Updated patch attached.
>>>
>>
>> Cool, I am happy with the patch now. Marking as ready for committer.
>
> Thanks for the review.

I don't much like splitting the code across multiple helper functions,
it makes the overall logic more difficult to follow, although I agree
that the indentation has made the pretty hard to read as it is. I'm
planning to commit the attached two patches. The first one is just
reformatting changes to ATExecAlterColumnType(), turning the switch-case
statements into if-else blocks. If-else doesn't cause so much
indentation, and allows defining variables local to the "cases" more
naturally, so it alleviates the indentation problem somewhat. The second
patch is the actual bug fix.

There was one bug in this patch: the COMMENT statement that was
constructed didn't schema-qualify the relation, so if the ALTERed table
was not in search_path, the operation would fail with a "relation not
found" error (or add the comment to wrong object). Fixed that.

I plan to commit the attached patches later today or tomorrow. But how
do you feel about back-patching this? It should be possible to
backpatch, although at a quick test it seems that there have been small
changes to the affected code in many versions, so it would require some
work. Also, in back-branches we'd need to put the new AT_ReAddComment
type to the end of the list, like we've done when we added
AT_ReAddConstraint in 9.3. I'm inclined to backpatch this to 9.5 only,
even though this is clearly a bug fix, on the grounds that it's not a
very serious bug and there's always some risk in backpatching.

- Heikki