Re: get_object_address support for additional object types

On 16 March 2015 at 15:11, Alvaro Herrera <alvherre@2ndquadrant.com> wrote:
>> > 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.
>

I'm getting a couple of compiler warnings that I think are coming from
this commit:

objectaddress.c: In function ‘get_object_address’:
objectaddress.c:1428:12: warning: array subscript is above array bounds
objectaddress.c:1430:11: warning: array subscript is above array bounds

I think because the compiler doesn't know the list size, so i could be 0,1,2.

Regards,
Dean