Re: BUG #13126: table constraint loses its comment

From: Petr Jelinek <petr(at)2ndquadrant(dot)com>
To: Michael Paquier <michael(dot)paquier(at)gmail(dot)com>, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
Cc: xi(at)resolvent(dot)net, PostgreSQL mailing lists <pgsql-bugs(at)postgresql(dot)org>, PostgreSQL-development <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: BUG #13126: table constraint loses its comment
Date: 2015-07-02 14:16:02
Message-ID: 559547A2.2000204@2ndquadrant.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-bugs pgsql-hackers

On 2015-05-27 15:10, Michael Paquier wrote:
> On Wed, Apr 29, 2015 at 1:30 PM, Michael Paquier
> <michael(dot)paquier(at)gmail(dot)com> wrote:
>> On Sun, Apr 26, 2015 at 6:05 AM, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> wrote:
>>> xi(at)resolvent(dot)net writes:
>>>> In some circumstances, the comment on a table constraint disappears. Here
>>>> is an example:
>>>
>>> Hm, yeah. The problem is that ATExecAlterColumnType() rebuilds all the
>>> affected indexes from scratch, and it isn't doing anything about copying
>>> their comments to the new objects (either comments on the constraints, or
>>> comments directly on the indexes).
>>>
>>> The least painful way to fix it might be to charter ATPostAlterTypeCleanup
>>> to create COMMENT commands and add those to the appropriate work queue,
>>> rather than complicating the data structure initially emitted by
>>> ATExecAlterColumnType. But it'd still be a fair amount of new code I'm
>>> afraid.
>>>
>>> Not planning to fix this personally, but maybe someone else would like to
>>> take it up.
>>
>> In order to fix this, an idea would be to add a new routine in
>> ruleutils.c that generates the COMMENT query string, and then call it
>> directly from tablecmds.c. On master, I imagine that we could even add
>> some SQL interface if there is some need.
>> Thoughts?
>
> After looking at this problem, I noticed that the test case given
> above does not cover everything: primary key indexes, constraints
> (CHECK for example) and indexes alone have also their comments removed
> after ALTER TABLE when those objects are re-created. I finished with
> the patch attached to fix everything, patch that includes a set of
> regression tests covering all the code paths added.
>

I was going through the code and have few comments:
- Why do you change the return value of TryReuseIndex? Can't we use
reuse the same OidIsValid(stmt->oldNode) check that ATExecAddIndex is
doing instead?

- I think the changes to ATPostAlterTypeParse should follow more closely
the coding of transformTableLikeClause - namely use the idxcomment

- Also the changes to ATPostAlterTypeParse move the code somewhat
uncomfortably over the 80 char width, I don't really see a way to fix
that except for moving some of the nesting out to another function.

--
Petr Jelinek http://www.2ndQuadrant.com/
PostgreSQL Development, 24x7 Support, Training & Services

In response to

Responses

Browse pgsql-bugs by date

  From Date Subject
Next Message bailuding 2015-07-03 01:54:41 BUG #13481: No config folder upon installation
Previous Message Fujii Masao 2015-07-02 13:00:10 Re: BUG #13368: standby cluster immediately promotes after pg_basebackup from previously promoted master

Browse pgsql-hackers by date

  From Date Subject
Next Message Simon Riggs 2015-07-02 14:29:01 Re: raw output from copy
Previous Message Alvaro Herrera 2015-07-02 14:14:09 Re: Re: [COMMITTERS] pgsql: Map basebackup tablespaces using a tablespace_map file