Re: [RFC] Common object property boards

Поиск
Список
Период
Сортировка
От Tom Lane
Тема Re: [RFC] Common object property boards
Дата
Msg-id 28185.1312823809@sss.pgh.pa.us
обсуждение исходный текст
Ответ на Re: [RFC] Common object property boards  (Robert Haas <robertmhaas@gmail.com>)
Ответы Re: [RFC] Common object property boards  (Robert Haas <robertmhaas@gmail.com>)
Список pgsql-hackers
Robert Haas <robertmhaas@gmail.com> writes:
> 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?

Not having an ABI break if we find it necessary to add members to the
struct ... which I grant is unlikely to happen in a minor version
update, but it could happen.

Having said that, the proposed coding with a single function returning N
pointer parameters seems like it's been written in the ugliest, least
efficient possible way, and it fails to resolve the ABI-break objection
anyway.  (If you did need another struct member, you'd also need another
return parameter, thus forcing recompiles.)  The form I had in mind was
N actual functions (not macros) that internally look like
sometypeget_object_property_foo(...){    structptr *p = get_object_property_struct(...);
    return p->foo;}

The only objection I can see to this is that somebody who needs several
different attributes of the same object would have to pay the lookup
cost several times.  That may or may not be an adequate reason to allow
people to fetch the struct directly; without seeing a list of places
where this would happen, it's impossible to evaluate the performance
costs.
        regards, tom lane


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

Предыдущее
От: Andres Freund
Дата:
Сообщение: Re: fstat vs. lseek
Следующее
От: Robert Haas
Дата:
Сообщение: Re: fstat vs. lseek