Re: type info refactoring

On sön, 2010-10-31 at 14:30 -0400, Robert Haas wrote:
> It's true that if the ostensible maximum length of a string or the
> precision of a numeric get lost somewhere on their path through the
> system, probably nothing terribly awful will happen. The worst case
> is that those values won't be enforced someplace where the user might
> expect it, and that's probably avoidable in most practical cases by
> adding an appropriate cast. I'm not sure whether it'll also be true
> for collation, because that affects comparison semantics, and getting
> the wrong comparison semantics is worse than failing to enforce a
> maximum length.

I think the problem is rather that we don't have a good answer for what
to do about propagating and combining typmods in all the cases. What
should varchar(10) || varchar(15) be? Probably varchar(25). What about
numeric(10) + numeric(15)? What about numeric(10) * numeric(15)? etc.
If we had a generalized answer to that, it might be possible to
implement it in the right places. (I'd guess it would be about half of
the size of the current collation patch.)

> Long story short, I'm inclined to view any data structure that is
> carrying only the type OID with great suspicion. If the additional
> information isn't needed today, it may well be tomorrow.

Maybe, but again this patch doesn't solve that. It just combines
existing OID + typmod into a single structure. It doesn't add typmods
where there were none before.