Re: get_object_address support for additional object types

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.

> 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.

> 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.

Works for me.

Thanks!

Stephen