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
