Re: deparsing utility commands

>
> My hope is to get this test module extended quite a bit, not only to
>>> cover existing commands, but also so that it causes future changes to
>>> cause failure unless command collection is considered. (In a previous
>>> version of this patch, there was a test mode that ran everything in the
>>> serial_schedule of regular regression tests. That was IMV a good way to
>>> ensure that new commands were also tested to run under command
>>> collection. That hasn't been enabled in the new test module, and I
>>> think it's necessary.)
>>>
>>
>>
>>> If anyone wants to contribute to the test module so that more is
>>> covered, that would be much appreciated.
>>>
>>
>> I'm planning to have a look at this part also.
>>
>
I've made some progress with this patch recently. Now I was able to get
rid of most errors in the deparsecheck run and it's time to have a look on
deparse_dump.errors. For now it can be summarized as follows:

src/test/regress$ wc -l results/deparse_dump.errors
147 results/deparse_dump.errors

src/test/regress$ < results/deparse_dump.errors sed
's/"[^"]*"\|[0-9]\+/???/g' | sort | uniq -c | sort -nr
98 ERROR: relation ??? does not exist
11 ERROR: column ??? of relation ??? does not exist
10 ERROR: role ??? does not exist
9 ERROR: large object ??? does not exist
6 ERROR: cannot alter type of column ??? twice
4 ERROR: column ??? of relation ??? already exists
2 ERROR: constraint ??? of relation ??? does not exist
1 ERROR: type public.rw_view??? does not exist
1 ERROR: schema ??? does not exist
1 ERROR: invalid value for parameter ???: ???
1 ERROR: invalid reference to FROM-clause entry for table ???
1 ERROR: index ??? does not exist
1 ERROR: column data type integer can only have storage PLAIN
1 ERROR: cannot alter type ??? because it is the type of a typed
table

A particularly nasty one is:

ERROR: index "cwi_replaced_pkey" does not exist

The test statement that's causing it is this one:

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

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.

--
Alex