Re: deparsing utility commands

Alvaro,

* Alvaro Herrera (alvherre(at)2ndquadrant(dot)com) wrote:
> Stephen Frost wrote:
> > I've started taking a look at this as the pgaudit bits depend on it and
> > noticed that the patch set implies there's 42 patches, but there were
> > only 37 attached..?
>
> Ah, I didn't realize when I posted that the subject was counting those
> extra patches. They are later patches that add the testing framework,
> but since the tests don't pass currently, they are not usable yet.
> Mostly they are about the running deparse_init.sql file that I posted
> separately. I will post a real patch for that stuff later today to make
> it clear what it is that we're talking about.

Oh, ok, no problem, just wanted to make sure things weren't missing.

> FWIW, one of Robert's main objections is that future hackers will forget
> to add deparse support for new commands as they are added. In an
> attempt to get this sorted out, I have modified the stuff in
> ProcessUtilitySlow() so that instead of having one
> EventTriggerStashCommand call for each node type, there is only one call
> at the end of the function. That way, new cases in the big switch there
> will automatically get something added to the stash, which should make
> the test fail appropriately. (Things like adding a new clause to
> existing commands will be tested by running pg_dump on the databases and
> comparing.)

Right, I've been following the discussion and fully agree with Robert
that we really need a way to make sure that future work doesn't forget
to address deparseing (or the various other bits, object classes, etc,
really). The approach you've outlined sounds interesting but I haven't
yet gotten to that bit of the code.

Thanks!

Stephen