On Mon, Aug 8, 2011 at 1:16 PM, Tom Lane <t...@sss.pgh.pa.us> wrote: > 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.
I think that would only be a problem if we added members to the middle of the struct, rather than at the end. However... > 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. ...doing it this way seems fine, because IIRC this is all only being used to support DDL operations, and the overhead of a few extra function calls isn't going to matter. -- Robert Haas EnterpriseDB: http://www.enterprisedb.com The Enterprise PostgreSQL Company -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers