On Sat, Dec 31, 2011 at 7:36 PM, Noah Misch <noah@leadboat.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
