Re: [RFC] Common object property boards

Поиск
Список
Период
Сортировка
От Kohei KaiGai
Тема Re: [RFC] Common object property boards
Дата
Msg-id CADyhKSWWfjg4ZW+GmX3ZrJLfKn4KVujeFOhwJV2VtSQzn0QnLw@mail.gmail.com
обсуждение исходный текст
Ответ на Re: [RFC] Common object property boards  (Robert Haas <robertmhaas@gmail.com>)
Список pgsql-hackers
2011/8/8 Robert Haas <robertmhaas@gmail.com>:
> 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.
>
I agree with Robert's opinion. It seems to me we have little benefit to
keep the structure condidential to other components.

Thanks,
--
KaiGai Kohei <kaigai@kaigai.gr.jp>


В списке pgsql-hackers по дате отправления:

Предыдущее
От: Heikki Linnakangas
Дата:
Сообщение: Re: Yes, WaitLatch is vulnerable to weak-memory-ordering bugs
Следующее
От: Alvaro Herrera
Дата:
Сообщение: Re: [RFC] Common object property boards