On Thu, Oct 15, 2015 at 1:51 AM, Noah Misch <n...@leadboat.com> wrote: > Tests of prm->prmtype and paramLI->paramFetch appear superfluous. Given that > the paramListCopyHook callback would return a complete substitute > ParamListInfo, I wouldn't expect SerializeParamList() to examine the the > original paramLI->params at all. If that's correct, the paramListCopyHook > design sounds fine. However, its implementation will be more complex than > paramMask would have been.
Well, I think there are two use cases we care about. If the ParamListInfo came from Bind parameters sent via a protocol message, then it will neither have a copy method nor require one. If it came from some source that plays fancy games, like PL/pgsql, then it needs a safe way to copy the list. >> This wouldn't require any >> modification to the current plpgsql_param_fetch() at all, but the new >> function would steal its bms_is_member() test. Furthermore, no user >> of ParamListInfo other than plpgsql needs to care at all -- which, >> with your proposals, they would. > > To my knowledge, none of these approaches would compel existing users to care. > They would leave paramMask or paramListCopyHook NULL and get today's behavior. Well, looking at this proposal: Bitmapset *paramMask; /* if non-NULL, ignore params lacking a 1-bit */ I read that to imply that every consumer of ParamListInfo objects would need to account for the possibility of getting one with a non-NULL paramMask. Would it work to define this as "if non-NULL, params lacking a 1-bit may be safely ignored"? Or some other tweak that basically says that you don't need to care about this, but you can if you want to. -- Robert Haas EnterpriseDB: http://www.enterprisedb.com The Enterprise PostgreSQL Company -- Sent via pgsql-hackers mailing list (email@example.com) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers