Extend phrase by an example
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.
Re: Extend phrase by an example
On Saturday, September 8, 2018, PG Doc comments form 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.
please inform data_directory
The following documentation comment has been logged on the website: Page: https://www.postgresql.org/docs/10/static/functions-admin.html Description: It is impossible to use pg_read_file(), etc. functions without SHOW data_directory
