Re: Add protransform for numeric, varbit, and temporal types

On Sat, Dec 31, 2011 at 7:36 PM, Noah Misch <noah(at)leadboat(dot)com> wrote:
> Building on commit 8f9fe6edce358f7904e0db119416b4d1080a83aa, this adds
> protransform functions to the length coercions for numeric, varbit, timestamp,
> timestamptz, time, timetz and interval.  This mostly serves to make more ALTER
> TABLE ALTER TYPE operations avoid a rewrite, including numeric(10,2) ->
> numeric(12,2), varbit(4) -> varbit(8) and timestamptz(2) -> timestamptz(4).
> The rules for varbit are exactly the same as for varchar.  Numeric is slightly
> more complex:
>
>  * Flatten calls to our length coercion function that solely represent
>  * increases in allowable precision.  Scale changes mutate every datum, so
>  * they are unoptimizable.  Some values, e.g. 1E-1001, can only fit into an
>  * unconstrained numeric, so a change from an unconstrained numeric to any
>  * constrained numeric is also unoptimizable.
>
> time{,stamp}{,tz} are similar to varchar for these purposes, except that, for
> example, plain "timestamptz" is equivalent to "timestamptz(6)".  interval has
> a vastly different typmod format, but the principles applicable to length
> coercion remain the same.
>
> Under --disable-integer-datetimes, I'm not positive that timestamp_scale() is
> always a no-op when one would logically expect as much.  Does there exist a
> timestamp such that v::timestamp(2) differs from v:timestamp(2)::timestamp(4)
> due to floating point rounding?  Even if so, I'm fairly comfortable calling it
> a feature rather than a bug to avoid perturbing values that way.
>
> After these patches, the only core length coercion casts not having
> protransform functions are those for "bpchar" and "bit".  For those, we could
> only optimize trivial cases of no length change.  I'm not planning to do so.

This is cool stuff. I will plan to review this once the CF starts.

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