From: | Peter Eisentraut <peter_e(at)gmx(dot)net> |
---|---|
To: | Robert Haas <robertmhaas(at)gmail(dot)com> |
Cc: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>, Heikki Linnakangas <heikki(dot)linnakangas(at)enterprisedb(dot)com>, pgsql-hackers(at)postgresql(dot)org |
Subject: | Re: type info refactoring |
Date: | 2010-10-31 22:13:49 |
Message-ID: | 1288563229.5712.26.camel@vanquo.pezone.net |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
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.
From | Date | Subject | |
---|---|---|---|
Next Message | Robert Haas | 2010-11-01 01:13:14 | Re: type info refactoring |
Previous Message | Dimitri Fontaine | 2010-10-31 22:09:23 | Re: ALTER OBJECT any_name SET SCHEMA name |