[ just for the archives' sake ]
Peter Geoghegan <peter@2ndquadrant.com> writes:
> On 27 March 2012 18:15, Tom Lane <tgl@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
