| From: | Noah Misch <noah(at)leadboat(dot)com> |
|---|---|
| To: | Jim Nasby <jim(at)nasby(dot)net> |
| Cc: | Alexey Klyukin <alexk(at)commandprompt(dot)com>, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>, Robert Haas <robertmhaas(at)gmail(dot)com>, pgsql-hackers(at)postgresql(dot)org |
| Subject: | Re: Identifying no-op length coercions |
| Date: | 2011-06-03 16:27:40 |
| Message-ID: | 20110603162740.GB30150@tornado.leadboat.com |
| Views: | Raw Message | Whole Thread | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-hackers |
On Fri, Jun 03, 2011 at 10:43:17AM -0500, Jim Nasby wrote:
> On Jun 3, 2011, at 10:11 AM, Alexey Klyukin wrote:
> >> Is your interest in cheap varchar(N)->varchar(N+M) conversions specifically, or
> >> in some broader application of this facility?
> >
> > Exactly varchar conversions.
>
> Why limit it to varchar? Shouldn't we be able to do this for any varlena? The only challenge I see is numeric; we'd need to ensure that both size and precision are not decreasing.
I've implemented support for varchar, varbit, numeric, time, timetz, timestamp,
timestamptz, and interval. However, I'll probably submit only varchar in the
initial infrastructure patch and the rest in followup patches in a later CF.
For numeric, we store the display scale in every datum, so any change to it
rewrites the table. You'll be able to cheaply change numeric(7,2) to
numeric(9,2) but not to numeric(9,3).
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Ross J. Reedstrom | 2011-06-03 16:32:26 | Re: Domains versus polymorphic functions, redux |
| Previous Message | Robert Haas | 2011-06-03 16:19:55 | Re: About bug #6049 |