On Mon, Aug 8, 2011 at 12:49 PM, Alvaro Herrera <alvhe...@commandprompt.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 >> <alvhe...@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.
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 -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
