On 3/17/16 7:40 PM, Tom Lane wrote:
> Chapman Flack <chap@anastigmatix.net> writes:
>> It seems that a typmod can only be used restrict the set of possible
>> values of the unmodified type (as clearly seen in the language "length
>> conversion cast", since certainly a typmod allowing { string | length < N }
>> is doing nothing but enforcing a subset of { string }. Each element of
>> the subset is still a valid element of the whole set (naturally, boring)
>> *and has to be represented the same way* (interesting): the representation
>> mustn't do clever things that you would need to know the typmod in order to
>> interpret, because most uses of a value are without access to the typmod.
>
> You do need to be able to interpret values of the type without having
> separate access to the typmod, but I don't think it follows that it's as
> restrictive as you say. One easy way around that is to store the typmod
> in the value.
>
> Practical uses might include compressing the data in different ways
> depending on typmod. I'm drawing a blank on other compelling examples
> though I'm sure there are some. Have you looked at PostGIS? I'm pretty
> sure some of their types make use of typmod in nontrivial ways.
If you want a non-trivial use of typmod, take a look at the (work in
progress) variant type I created[1]. It allows you pass names of
"registered variants" in via typmod. The idea behind that is to restrict
what types you can actually store in a particular variant field (though
you can also disallow a registered variant from being used in a table
definition).
I did run into some cases where Postgres ignored typmod, so I special
case the default typmod (-1) to a registered variant that's disabled.
[1]
https://github.com/BlueTreble/variant/blob/master/doc/variant.md#variant-modifier
--
Jim Nasby, Data Architect, Blue Treble Consulting, Austin TX
Experts in Analytics, Data Architecture and PostgreSQL
Data in Trouble? Get it in Treble! http://BlueTreble.com