On 4/16/19 9:42 AM, Tom Lane wrote:
> Adrian Klaver <adrian.klaver@aklaver.com> writes:
>> I suspect the OP wants the type to text with a CHECK constraint to allow
>> for increasing the length of field values in the future by just changing
>> the CHECK setting. If that is the case would changing the type to text
>> and then adding a CHECK NOT VALID work without too much pain?
> I don't think we really support NOT VALID on domain constraints do we?
>
> In any case, the point remains that domains are pretty inefficient
> compared to native types like varchar(12); partly because the system
> can't reason very well about arbitrary check constraints as compared
> to simple length constraints, and partly because the whole feature
> just isn't implemented very completely or efficiently. So you'll be
> paying *a lot* for some hypothetical future savings.
Domains are great for maintaining data type consistency across many
tables/columns. Normalization can obviate much of that need, and
denormalization increases it.
> (Having said that, you're already paying a fair chunk of that
> overhead with your existing domain type, so maybe it's not bothering
> you. But I'm worried that going from domain-without-check-constraint
> to domain-with-check-constraint is going to bite you.)
>
> regards, tom lane
>
>
--
Angular momentum makes the world go 'round.