| From: | "David G(dot) Johnston" <david(dot)g(dot)johnston(at)gmail(dot)com> |
|---|---|
| To: | "kes-kes(at)yandex(dot)ru" <kes-kes(at)yandex(dot)ru>, "pgsql-docs(at)lists(dot)postgresql(dot)org" <pgsql-docs(at)lists(dot)postgresql(dot)org> |
| Subject: | Re: Extend phrase by an example |
| Date: | 2018-09-09 15:11:05 |
| Message-ID: | CAKFQuwbEp6j26OBWT8NbLt0e_f_o+bRoczwHChdv=7sr_AKABw@mail.gmail.com |
| Views: | Raw Message | Whole Thread | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-docs |
On Saturday, September 8, 2018, PG Doc comments form <noreply(at)postgresql(dot)org>
wrote:
> the constraints shown in the table
> definition do not apply to values of the composite type outside the table.
> (A partial workaround is to use domain types as members of composite
> types.)
>
> The part:
> >(A partial workaround is to use domain types as members of composite
> types.)
>
> From here I can understand that workaround is possible.
>
> But what is workaround? and why it is partial?
> Would be great to have this description.
>
The main thing is that some constraints are implemented via triggers and
those can only be attached to actual tables. So in the example the
REFERENCES constraint can only be used on the original table records and
can never applied to a standalone value of that type.
David J.
| From | Date | Subject | |
|---|---|---|---|
| Next Message | PG Doc comments form | 2018-09-09 23:41:36 | please inform data_directory |
| Previous Message | PG Doc comments form | 2018-09-08 13:27:14 | Extend example of JOIN results for completeness |