Skip site navigation (1) Skip section navigation (2)

Re: type info refactoring

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: (view raw, whole thread or download thread mbox)
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.

In response to


pgsql-hackers by date

Next:From: Robert HaasDate: 2010-11-01 01:13:14
Subject: Re: type info refactoring
Previous:From: Dimitri FontaineDate: 2010-10-31 22:09:23
Subject: Re: ALTER OBJECT any_name SET SCHEMA name

Privacy Policy | About PostgreSQL
Copyright © 1996-2018 The PostgreSQL Global Development Group