Re: [RFC] Common object property boards - Mailing list pgsql-hackers

From Tom Lane
Subject Re: [RFC] Common object property boards
Date
Msg-id 28185.1312823809@sss.pgh.pa.us
Whole thread Raw
In response to Re: [RFC] Common object property boards  (Robert Haas <robertmhaas@gmail.com>)
Responses Re: [RFC] Common object property boards
List 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 by date:

Previous
From: Andres Freund
Date:
Subject: Re: fstat vs. lseek
Next
From: Robert Haas
Date:
Subject: Re: fstat vs. lseek