From: | Ron <ronljohnsonjr(at)gmail(dot)com> |
---|---|
To: | pgsql-general(at)lists(dot)postgresql(dot)org |
Subject: | Re: Alter domain type / avoiding table rewrite |
Date: | 2019-04-16 15:08:32 |
Message-ID: | c2a2f6f0-9e85-3c43-54d5-b68c592695ed@gmail.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-general |
On 4/16/19 9:42 AM, Tom Lane wrote:
> Adrian Klaver <adrian(dot)klaver(at)aklaver(dot)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.
From | Date | Subject | |
---|---|---|---|
Next Message | Tim Kane | 2019-04-16 16:18:37 | Re: Alter domain type / avoiding table rewrite |
Previous Message | Ron | 2019-04-16 15:04:58 | Re: Alter domain type / avoiding table rewrite |