From: | Joe Abbate <jma(at)freedomcircle(dot)com> |
---|---|
To: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
Cc: | pgsql-general(at)lists(dot)postgresql(dot)org |
Subject: | Re: DOMAIN/composite TYPE vs. base TYPE |
Date: | 2020-09-28 21:58:19 |
Message-ID: | 57a90723-04cd-2036-7184-83e9409f8206@freedomcircle.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-general |
Hello Tom,
On 28/9/20 17:25, Tom Lane wrote:
> Domain-over-composite might be a slightly simpler answer than your first
> one. It's only available in relatively late-model PG, and I'm not sure
> about its performance relative to your other design, but it is an
> alternative to think about.
"Domain-over-composite" meaning create a TYPE first (DATE, CHAR(1)) and
then a DOMAIN based on that type? (1) How late model are we talking?
The DOMAIN syntax doesn't seem changed from PG 11 to PG 13? (2) Can a
CHECK constraint specify attributes of the composite?
> Note that attaching NOT NULL constraints at the domain level is almost
> never a good idea, because then you find yourself with a semantically
> impossible situation when, say, a column of that type is on the nullable
> side of an outer join. We allow such constraints, but they will be
> nominally violated in cases like that.
NULLs: Tony Hoare's "billion dollars of pain and damage" transported to SQL.
Joe
From | Date | Subject | |
---|---|---|---|
Next Message | Joe Abbate | 2020-09-28 22:05:42 | Re: DOMAIN/composite TYPE vs. base TYPE |
Previous Message | Gavan Schneider | 2020-09-28 21:52:14 | Re: DOMAIN/composite TYPE vs. base TYPE |