Re: deparsing utility commands - Mailing list pgsql-hackers

From Alvaro Herrera
Subject Re: deparsing utility commands
Date
Msg-id 20150227222959.GN2384@alvh.no-ip.org
Whole thread Raw
In response to Re: deparsing utility commands  (Stephen Frost <sfrost@snowman.net>)
Responses Re: deparsing utility commands  (Stephen Frost <sfrost@snowman.net>)
List pgsql-hackers
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

Attachment

pgsql-hackers by date:

Previous
From: Tom Lane
Date:
Subject: Re: MemoryContext reset/delete callbacks
Next
From: Josh Berkus
Date:
Subject: Re: logical column ordering