Re: type info refactoring

On Sun, Oct 31, 2010 at 6:13 PM, Peter Eisentraut <peter_e(at)gmx(dot)net> wrote:
> 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.)

I think the answer is that in some of those cases it doesn't matter,
and that just saying it's plain old numeric is fine. But that's not
necessarily true for all possible uses of typmodish stuff.

>> 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.

OK. That seems like a good place to start.

--
Robert Haas
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company