BTW, there is another way in which the current rules for transform
application are not self-consistent. Postgres has three kinds of
container types: arrays, composites, and ranges. But the transform
code special-cases only arrays. I'd have thought that if the idea is
to specify transforms only for base types, then TRANSFORM FOR TYPE
ought to recurse into composites and list their field types in
protrftypes. It doesn't, but if you look at plpython it appears
that
(1) you can create a transform for a composite type and it will be
applied;
(2) if you don't, the code recurses to the fields and will apply
per-field-type transforms then.
plperl will effectively do (1) but not (2), if I'm reading it right.
Ranges are a bit odd in that their semantics are not just a collection
of element/field types, so it perhaps makes sense that we don't
attempt to apply base-type transforms to their contents. But it's
sure inconsistent that arrays and composites aren't handled more
nearly alike here.
regards, tom lane
