From: | Dean Rasheed <dean(dot)a(dot)rasheed(at)gmail(dot)com> |
---|---|
To: | Alvaro Herrera <alvherre(at)2ndquadrant(dot)com> |
Cc: | Stephen Frost <sfrost(at)snowman(dot)net>, Pg Hackers <pgsql-hackers(at)postgresql(dot)org> |
Subject: | Re: get_object_address support for additional object types |
Date: | 2015-03-16 21:05:54 |
Message-ID: | CAEZATCVy11woH3iHuBS79+uFpPAuiBBWm=D0swtafU5CfPSj_Q@mail.gmail.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
On 16 March 2015 at 15:11, Alvaro Herrera <alvherre(at)2ndquadrant(dot)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
From | Date | Subject | |
---|---|---|---|
Next Message | Alvaro Herrera | 2015-03-16 23:44:06 | Re: deparsing utility commands |
Previous Message | Tom Lane | 2015-03-16 21:01:43 | Re: Additional role attributes && superuser review |