Alvaro, * Alvaro Herrera (alvhe...@2ndquadrant.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
signature.asc
Description: Digital signature
