Re: [RFC] Common object property boards

On Mon, Aug 8, 2011 at 1:16 PM, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> wrote:
> Robert Haas <robertmhaas(at)gmail(dot)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