Re: deparsing utility commands - Mailing list pgsql-hackers

From Stephen Frost
Subject Re: deparsing utility commands
Date
Msg-id 20150218213255.GC6717@tamriel.snowman.net
Whole thread Raw
In response to Re: deparsing utility commands  (Alvaro Herrera <alvherre@2ndquadrant.com>)
Responses Re: deparsing utility commands  (Alvaro Herrera <alvherre@2ndquadrant.com>)
List pgsql-hackers
* Alvaro Herrera (alvherre@2ndquadrant.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.

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,
    Stephen

pgsql-hackers by date:

Previous
From: Alvaro Herrera
Date:
Subject: Re: deparsing utility commands
Next
From: Peter Geoghegan
Date:
Subject: Re: INSERT ... ON CONFLICT {UPDATE | IGNORE} 2.0