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

Re: type info refactoring

From: Robert Haas <robertmhaas(at)gmail(dot)com>
To: Peter Eisentraut <peter_e(at)gmx(dot)net>
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-11-01 01:13:14
Message-ID: AANLkTi=SnMMB=C3Z86igDAVs5bNg7kHenbcWeZgvkWqO@mail.gmail.com (view raw or flat)
Thread:
Lists: pgsql-hackers
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

In response to

pgsql-hackers by date

Next:From: Robert HaasDate: 2010-11-01 03:04:26
Subject: Re: [PATCH] More Coccinelli cleanups
Previous:From: Peter EisentrautDate: 2010-10-31 22:13:49
Subject: Re: type info refactoring

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