Re: [RFC] Common object property boards

From: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
To: Robert Haas <robertmhaas(at)gmail(dot)com>
Cc: Alvaro Herrera <alvherre(at)commandprompt(dot)com>, Kohei KaiGai <kaigai(at)kaigai(dot)gr(dot)jp>, Kohei Kaigai <kohei(dot)kaigai(at)emea(dot)nec(dot)com>, Pg Hackers <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: [RFC] Common object property boards
Date: 2011-08-08 17:16:49
Message-ID: 28185.1312823809@sss.pgh.pa.us
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

Robert Haas <robertmhaas(at)gmail(dot)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

sometype
get_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

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Robert Haas 2011-08-08 17:19:13 Re: fstat vs. lseek
Previous Message Andres Freund 2011-08-08 17:10:05 Re: fstat vs. lseek