Robert Haas <robertmh...@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
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
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
