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

From Alvaro Herrera
Subject Re: [RFC] Common object property boards
Date
Msg-id 1312821895-sup-3108@alvh.no-ip.org
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
Excerpts from Robert Haas's message of lun ago 08 12:33:45 -0400 2011:
> On Mon, Aug 8, 2011 at 12:22 PM, Alvaro Herrera
> <alvherre@commandprompt.com> wrote:
> > Excerpts from Robert Haas's message of lun ago 08 12:05:05 -0400 2011:
> >> 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?  I feel
> >> like we're making this ludicrously complicated with no real
> >> justification of why all of this complexity is adding any value.
> >
> > I don't see that it's complicated in any way.  Seems pretty simple to me.
> 
> It's quite complicated.  Every time someone adds a new member to the
> struct, they need to adjust the code all over the place.  The call
> sequence of the accessor function will constantly be changing.

You are rehashing an argument that I already rebutted: the way to solve
this problem is with the macros, the format of which we were discussing
in this sub-thread.  I am not sure why you bring it up again.

You say the reason for not exporting the struct definition is that you
can later change it without having to touch the callers.  That seems a
good argument, and it seems to me to work equally for pg_amop as for the
new header KaiGai is creating here.

In any case, at the start of the thread KaiGai was asking for opinions,
and I gave mine.  I will now shut up.

-- 
Álvaro Herrera <alvherre@commandprompt.com>
The PostgreSQL Company - Command Prompt, Inc.
PostgreSQL Replication, Consulting, Custom Development, 24x7 support


pgsql-hackers by date:

Previous
From: Kohei KaiGai
Date:
Subject: Re: [RFC] Common object property boards
Next
From: Andres Freund
Date:
Subject: Re: fstat vs. lseek