Re: deparsing utility commands

Stephen Frost wrote:
> * Alvaro Herrera (alvherre(at)2ndquadrant(dot)com) wrote:
> > > > Now, we probably don't want to hack *all* the utility commands to return
> > > > ObjectAddress instead of OID, because it many cases that's just not
> > > > going to be convenient (not to speak of the code churn); so I think for
> > > > most objtypes the ProcessUtilitySlow stanza would look like this:
> >
> > > 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).
> >
> > Well, that would make my life easier I think (even if it's a bit more
> > work), so unless there are objections I will do things this way. It's a
> > bit of a pity that Robert and Dimitri went to huge lengths to have these
> > functions return OID and we're now changing it all to ObjAddress
> > instead, but oh well.
>
> Not sure that I see it as that huge a deal.. They're still returning an
> Oid, it's just embedded in the ObjAddress to provide a complete
> statement of what the object is.

I've been looking at this idea some more. There's some churn, but it's
not that bad. For instance, here's the patch to have RENAME return
ObjectAddress rather than OIDs.

For instance, the get_objtype_catalog_id() function, provided in a later
patch in the series, will no longer be necessary; instead, each
execution code path in the src/backend/command code must set the correct
catalog ID in the ObjectAddress it returns. So the event triggers code
will have the catalog ID at the ready, without having to figure it out
from the ObjectType it gets from the parse node.

> btw, the hunk in 0026 which adds a 'break;' into standard_ProcessUtility
> caught me by surprise. Looks like that 'break;' was missing from 0003
> (for T_GrantStmt).

Thanks for pointing this out -- that was broken rebase.

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