Thomas Lockhart <lockhart@alumni.caltech.edu> writes:
> Ah, right; "bpchar" is "blank padded char". But would there be any
> downside to removing those blank pads when doing the transformation
> back to a printed query? i.e. if the outnode() functions stripped the
> padding? Or maybe at that point there is not enough info to do it?
There's not enough info to know whether trailing spaces were inserted
by the system or given by the user. I'd be pretty uncomfortable with
trying to make outfuncs.c apply a potentially semantics-changing
transformation like that. It isn't nearly smart enough to do the right
thing at present, and trying to make it smart enough seems like the
wrong direction to go in.
> Seems like an ill-advised char(2000) or two in a table might bollux up
> a lot of potential rules (even more than my extraneous column aliases
> might ;)
Good point... of course people will be hitting other problems besides
rule length with such things, but...
Perhaps the right answer here is that addition of length-coercion
functions to an INSERT or UPDATE's targetlist entries doesn't belong
in the parser, but should be handled downstream of the rule stuff
--- right before the planner's constant-folding step seems like a
good spot. Then we wouldn't be paying for either the padding (if
the function got constant-folded out) or the function call (if not)
in the stored rule's querytree.
This would also allow ruleutils.c to get rid of some grotty code it has
to try to hide said functions in the reverse-listed query. Might make
life a little easier for the rule rewriter too, I dunno.
regards, tom lane