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