On 16 March 2015 at 15:11, Alvaro Herrera <alvhe...@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 -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
