Robert Haas <robertmhaas@gmail.com> writes:
> On Fri, Jun 12, 2020 at 2:14 PM Tom Lane <tgl@sss.pgh.pa.us> wrote:
>> Robert Haas <robertmhaas@gmail.com> writes:
>>> BTW, has there been any thought to supporting a negative scale for the
>>> numeric data type? If you can cut off digits after the decimal, why
>>> not before?
>> Hm, would there be any real use-case?
> Compatibility... apparently people do use it.
Uh, compatibility with what? Not the SQL spec, for sure.
>> An implementation issue is that even in the "long" numeric format,
>> we cram dscale into a 14-bit unsigned field.
> That doesn't sound too appealing I guess, but couldn't you enforce it
> as a typemod without changing the on-disk representation of the
> values?
On second thought, I'm confusing two distinct though related concepts.
dscale is *display* scale, and it's fine that it's unsigned, because
there is no reason to suppress printing digits to the left of the decimal
point. ("Whaddya mean, 10 is really 100?") We could allow the "scale"
part of typmod to be negative and thereby cause an input of, say,
123.45 to be rounded to say 100 --- but it should display as 100 not 1,
so its display scale is still 0.
Hence, there's no pg_upgrade issue. You'd still need to rethink how
precision and scale get packed into an int32 typmod, but those only
exist in catalog data, so pg_upgrade's schema dump/restore would be
enough to update them.
Having said that, we've long resisted redefining the encoding of
typmod for other data types (despite the clear insanity of some
of the encodings), for fear that client code might be looking at
those catalog columns. I'm not sure how big a deal that really is.
regards, tom lane
