Extend phrase by an example

Started by PG Bug reporting formover 7 years ago2 messagesdocs
Jump to latest
#1PG Bug reporting form
noreply@postgresql.org

The following documentation comment has been logged on the website:

Page: https://www.postgresql.org/docs/10/static/rowtypes.html
Description:

Hi.
On the page:
https://www.postgresql.org/docs/10/static/rowtypes.html

then the same inventory_item composite type shown above would come into

being as a byproduct, and could be used just as above. Note however an
important restriction of the current implementation: since no constraints
are associated with a composite type, 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.

#2David G. Johnston
david.g.johnston@gmail.com
In reply to: PG Bug reporting form (#1)
Re: Extend phrase by an example

On Saturday, September 8, 2018, PG Doc comments form <noreply@postgresql.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.