[ just for the archives' sake ] Peter Geoghegan <pe...@2ndquadrant.com> writes: > On 27 March 2012 18:15, Tom Lane <t...@sss.pgh.pa.us> wrote: >> Now, if what it wants to know about is the parameterization status >> of the query, things aren't ideal because most of the info is hidden >> in parse-callback fields that aren't of globally exposed types. However >> we could at least duplicate the behavior you have here, because you're >> only passing canonicalize = true in cases where no parse callback will >> be registered at all, so pg_stat_statements could equivalently test for >> pstate->p_paramref_hook == NULL.
> It has been suggested to me before that comparisons with function > pointers - using them as a flag, in effect - is generally iffy, but > that particular usage seems reasonable to me. Well, testing function pointers for null is certainly OK --- note that all our hook function call sites do that. It's true that testing for equality to a particular function's name can fail on some platforms because of jump table hacks. Thus for example, if you had a need to know that parse_variable_parameters parameter management was in use, it wouldn't do to test whether p_coerce_param_hook == variable_coerce_param_hook. (Not that you could anyway, what with that being a static function, but exposing it as global wouldn't offer a safe solution.) If we had a need to make this information available, I think what we'd want to do is insist that p_ref_hook_state entries be subclasses of Node, so that plugins could apply IsA tests on the node tag to figure out what style of parameter management was in use. This would also mean exposing the struct definitions globally, which you'd need anyway else the plugins couldn't safely access the struct contents. I don't particularly want to go there without very compelling reasons, but that would be the direction to head in if we had to. regards, tom lane -- Sent via pgsql-hackers mailing list (email@example.com) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers