Re: get_object_address support for additional object types

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.

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.

The only thing a bit unusual is that in does_not_exist_skipping() we
need to do an list_copy_tail() to strip out the amname before reporting
the "skipping" message, for DROP OPERATOR CLASS/FAMILY IF NOT EXISTS.
I don't think this is a problem.  In return, the code to deconstruct
amop and amproc addresses is more sensible.

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