public inbox for [email protected]  
help / color / mirror / Atom feed
Extend phrase by an example
2+ messages / 2 participants
[nested] [flat]

* Extend phrase by an example
@ 2018-09-08 11:56 PG Doc comments form <[email protected]>
  2018-09-09 15:11 ` Re: Extend phrase by an example David G. Johnston <[email protected]>
  0 siblings, 1 reply; 2+ messages in thread

From: PG Doc comments form @ 2018-09-08 11:56 UTC (permalink / raw)
  To: [email protected]; +Cc: [email protected]

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.


^ permalink  raw  reply  [nested|flat] 2+ messages in thread

* Re: Extend phrase by an example
  2018-09-08 11:56 Extend phrase by an example PG Doc comments form <[email protected]>
@ 2018-09-09 15:11 ` David G. Johnston <[email protected]>
  0 siblings, 0 replies; 2+ messages in thread

From: David G. Johnston @ 2018-09-09 15:11 UTC (permalink / raw)
  To: [email protected] <[email protected]>; [email protected] <[email protected]>

On Saturday, September 8, 2018, PG Doc comments form <[email protected]>
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.


^ permalink  raw  reply  [nested|flat] 2+ messages in thread


end of thread, other threads:[~2018-09-09 15:11 UTC | newest]

Thread overview: 2+ messages (download: mbox mbox.gz follow: Atom feed)
-- links below jump to the message on this page --
2018-09-08 11:56 Extend phrase by an example PG Doc comments form <[email protected]>
2018-09-09 15:11 ` David G. Johnston <[email protected]>

This inbox is served by agora; see mirroring instructions
for how to clone and mirror all data and code used for this inbox