Re: [RFC] Common object property boards - Mailing list pgsql-hackers

From Robert Haas
Subject Re: [RFC] Common object property boards
Date
Msg-id CA+TgmoZhU_N10pFH0TOu4rPR580EsWgdV_iD5fPCnHcACSW=Lw@mail.gmail.com
Whole thread Raw
In response to Re: [RFC] Common object property boards  (Alvaro Herrera <alvherre@commandprompt.com>)
Responses Re: [RFC] Common object property boards
Re: [RFC] Common object property boards
Re: [RFC] Common object property boards
List pgsql-hackers
On Mon, Aug 8, 2011 at 11:57 AM, Alvaro Herrera
<alvherre@commandprompt.com> wrote:
> Excerpts from Kohei KaiGai's message of lun ago 08 03:12:20 -0400 2011:
>
>> Thanks for your suggestion.
>> So, it seems to me the interface should return a pointer to the entry
>> of array being specified, rather than above approach.
>>
>> E.g, the above macro could be probably rewritten as follows:
>>   #define get_object_property_attnum_name(objtype) \
>>       (get_object_property(objtype)->attnum_name)
>
> I don't understand why don't you just do something like
>
>   #define get_object_property_attnum_name(objtype, attnum_name_value) \
>       (get_object_property((objtype), NULL, NULL, (attnum_name_value), NULL, NULL)))
>
> and the caller does
>
> AttrNumber      attnum_name;
> get_object_property_attnum_name(OBJTYPE_TABLE, &attnum_name);
>
> i.e. the caller must still pass pointers, instead of expecting the
> values to be returned.

We could do that, but what the heck is the point?   What benefit are
we trying to get by not returning a pointer to the structure?  I feel
like we're making this ludicrously complicated with no real
justification of why all of this complexity is adding any value.

--
Robert Haas
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company


pgsql-hackers by date:

Previous
From: Alvaro Herrera
Date:
Subject: Re: [RFC] Common object property boards
Next
From: Robert Haas
Date:
Subject: Re: per-column FDW options, v5