Peter Eisentraut <peter_e@gmx.net> writes:
> Tom Lane writes:
>> CREATE TABLE AS cannot be expected to be able to extract a suitable
>> typmod from complex expressions.
> I don't think that would be entirely unreasonable.
Well, it might not be completely impossible, but I think it's well on
the far side of unreasonable. For *every operator* that produces a
result of any of the typmod-using types, we'd have to maintain an
auxiliary bit of code that can predict the result typmod. That's
a lot of code, and when you start considering user-defined functions
it gets worse. And all for what? Not to do anything useful, but only
to *eliminate* functionality. Perhaps char without typmod is
unnecessary (since it reduces to text), but numeric without typmod seems
highly useful to me.
Strikes me as a very large amount of work to go in the wrong
direction...
> A possible solution would be that data types can register a
> typmod-resolver function, which takes two typmods and returns the typmod
> to make both expressions union-compatible.
This only handles the UNION and CASE merge scenarios.
It'd probably be reasonable for UNION/CASE to copy the input typmod
if the alternatives all agree on the type and typmod. But solving
the general problem would be a lot of work of dubious value.
regards, tom lane