Re: [RFC] Common object property boards

On Mon, Aug 8, 2011 at 12:49 PM, Alvaro Herrera
<alvherre(at)commandprompt(dot)com> wrote:
> 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(at)commandprompt(dot)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.

Well, the proposed macro design seems like it doesn't go as far in
that direction as I would have hoped. I thought you were proposing to
have one function that returns a pointer to the struct, and then a
bunch of macros that return particular elements out of the returned
struct. If we did that, the macro definitions wouldn't need to change
when you added new members to the struct. On the other hand, if you
have one function with N out parameters, and the macros are just
calling that function with mostly NULL arguments, then the calls have
to be updated every time you add a new struct member. IMHO, that's a
pain. YMMV.

> 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 the case of pg_amop, there's an additional thing to worry about,
which is that the result is allocated in some memory context, and you
now have to worry about how long it sticks around in that context vs.
how long the caller needs it for. Copying the data into out
parameters (or a pg_amop struct in the caller's memory context, if we
had preferred to go that route) addresses that problem. However, here
we're just dealing with static data, so that's not a problem.

Also, if get_op_opfamily_properties() had as many out parameters as
this function would likely need to, I'd favor changing that, too.
Three is reasonable. Ten is pushing it, and any more than that is
kind of nuts. I think we're going to end up with quite a few in this
case, because we're rapidly accreting a set of operations that work on
"any old SQL object" (COMMENT, SECURITY LABEL, ALTER EXTENSION ..
ADD/DROP, ALTER FOO .. SET SCHEMA, etc.). I think that's a good
thing, but I don't want to assume that the number of struct members is
going to remain small.

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

Sorry to have given offense. My goal was to understand why we were
having this argument, not to piss you off. However, I seem to have
failed.

--
Robert Haas
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company