Re: deparsing utility commands - Mailing list pgsql-hackers

From Shulgin, Oleksandr
Subject Re: deparsing utility commands
Date
Msg-id CACACo5QdX-22CnK6qjvW=t4eLE6vZM2UEUKc36JPCuUqvhyDoA@mail.gmail.com
Whole thread Raw
In response to Re: deparsing utility commands  ("Shulgin, Oleksandr" <oleksandr.shulgin@zalando.de>)
Responses Re: deparsing utility commands  (Alvaro Herrera <alvherre@2ndquadrant.com>)
List pgsql-hackers
On Thu, Aug 20, 2015 at 4:28 PM, Shulgin, Oleksandr <oleksandr.shulgin@zalando.de> wrote:
 
Which gets deparsed as:

ALTER TABLE cwi_test DROP CONSTRAINT cwi_uniq_idx,
ADD CONSTRAINT cwi_replaced_pkey PRIMARY KEY
USING INDEX cwi_replaced_pkey;

The problem is that during constraint transformation, the index is being renamed to match the constraint name and at the deparse stage the original index name appears to be lost completely...  I haven't figure out if there's a way around unless we introduce a new field in IndexStmt (originalName?) to cover exactly this corner case.

The updated versions of the core-support patch and the contrib modules are attached.

Another quirk of ALTER TABLE is that due to multi-pass processing in ATRewriteCatalogs, the same command might be collected a number of times.  For example, in src/test/regress/sql/inherit.sql:

alter table a alter column aa type integer using bit_length(aa);

the "alter column type" then appears 4 times in the deparsed output as identical subcommands of a single ALTER TABLE command.

pgsql-hackers by date:

Previous
From: Tom Lane
Date:
Subject: Re: (full) Memory context dump considered harmful
Next
From: David Brownlee
Date:
Subject: Re: PostgreSQL for VAX on NetBSD/OpenBSD