Re: deparsing utility commands

Stephen Frost wrote:

> > and at the bottom of the loop we would transform the objid/type into
> > address for the cases that need it:
> >
> > if (!commandStashed)
> > {
> > if (objectId != InvalidOid)
> > {
> > address.classId = get_objtype_catalog_oid(objectType);
> > address.objectId = objectId;
> > address.objectSubId = 0;
> > }
> > EventTriggerStashCommand(address, secondaryOid, parsetree);
> > }
>
> That'd be fine with me, though for my 2c, I wouldn't object to changing
> them all to return ObjectAddress either. I agree that it'd cause a fair
> bit of code churn to do so, but there's a fair bit of code churn
> happening here anyway (looking at what 0008 does to ProcessUtilitySlow
> anyway).

Thanks. I have adjusted the code to use ObjectAddress in all functions
called by ProcessUtilitySlow; the patch is a bit tedious but seems
pretty reasonable to me. As I said, there is quite a lot of churn.

Also attached are some patches to make some commands return info about
a secondary object regarding the execution, which can be used to know
more about what's being executed:

1) ALTER DOMAIN ADD CONSTRAINT returns (in addition to the address of
the doamin) the address of the new constraint.

2) ALTER OBJECT SET SCHEMA returns (in addition to the address of the
object) the address of the old schema.

3) ALTER EXTENSION ADD/DROP OBJECT returns (in addition to the address
of the extension) the address of the added/dropped object.

Also attached is the part of these patches that have ALTER TABLE return
the AttrNumber and OID of the affected object.

I think this is all mostly uninteresting, but thought I'd throw it out
for public review before pushing, just in case. I have fixed many
issues in the rest of the branch meanwhile, and it's looking much better
IMO, but much work remains there and will leave them for later.

--
Álvaro Herrera http://www.2ndQuadrant.com/
PostgreSQL Development, 24x7 Support, Remote DBA, Training & Services