On Thu, Oct 15, 2015 at 12:05:53PM -0400, Robert Haas wrote: > On Thu, Oct 15, 2015 at 1:51 AM, Noah Misch <n...@leadboat.com> wrote:
> >> 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. Agreed. More specifically, I had in mind for copyParamList() to check the mask while e.g. ExecEvalParamExtern() would either check nothing or merely assert that any mask included the requested parameter. It would be tricky to verify that as safe, so ... > 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. ... this is a better specification. -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
