Re: Michael Paquier
> I have been thinking about this patch for a couple of days. What
> makes me unhappy in this proposal is that RangeTblEntry is a large and
> complicated Node, and we only want to force a custom computation for
> the "relid" portion of the node, while being able to also take some
> decisions for what the parent node has. Leaving the existing
> per-field query_jumble_ignore with the custom function is prone to
> errors, as well, because we need to maintain some level of consistency
> between parsenodes.h and src/backend/nodes/.
Ack, that was also bothering me, but I didn't think it was so easy to
do it on a per-field level. Thanks!
> The custom functions are named _jumble${node}_${field}, with the field
> and the parent node given as arguments. I agree that giving the field
> is kind of pointless if you have the parent node, but I think that
> this is better so as this forces developers to think about how to use
> the field value with the node.
Makes sense.
> Please see the attached. What do you think?
Just one minor thing, I don't understand what you are trying to say in
this comment:
> +/*
> + * Note that the argument types are enforced for the per-field custom
> + * functions.
> + */
> +#define JUMBLE_CUSTOM(nodetype, item) \
> + _jumble##nodetype##_##item(jstate, expr, expr->item)
Thanks,
Christoph
