Re: get_object_address support for additional object types

Stephen Frost wrote:
> Alvaro,
>
> * Alvaro Herrera (alvherre(at)2ndquadrant(dot)com) wrote:
> > Stephen Frost wrote:
> > > I thought the rest of it looked alright. I agree it's a bit odd how the
> > > opfamily is handled but I agree with your assessment that there's not
> > > much better we can do with this object representation.
> >
> > Actually, on second thought I revisited this and changed the
> > representation for opfamilies and opclasses: instead of putting the AM
> > name in objargs, we can put it as the first element of objname instead.
> > That way, objargs is unused for opfamilies and opclasses, and we're free
> > to use it for the type arguments in amops and amprocs. This makes the
> > lists consistent for the four cases: in objname, amname first, then
> > qualified opclass/opfamily name. For amop/amproc, the member number
> > follows. Objargs is unused in opclass/opfamily, and it's a two-element
> > list of types in amop/amproc.
>
> Agreed, that makes more sense to me also.

Great, thanks for checking -- pushed that way.

> > The attached patch changes the grammar to comply with the above, and
> > adds the necessary get_object_address and getObjectIdentityParts support
> > code for amop/amproc objects.
>
> I took a quick look through and it looked fine to me.

Actually, there was a bug in the changes of the rule for ALTER EXTENSION
ADD OPERATOR CLASS. I noticed by chance only, and upon testing it
manually I realized I had made a mistake. I then remembered I made the
same bug previously, fixed by 5c5ffee80f35, and I'm not wondering why do
we not have any test for ALTER EXTENSION ADD other than pg_upgrading
some database that contains an extension which uses each command. This
seems pretty dangerous to me, generally speaking ... we should
definitely be testing all these ALTER EXTENSION commands.

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