[DOCS] Cross-references between DOMAIN and POLICY
The following documentation comment has been logged on the website: Page: https://www.postgresql.org/docs/9.6/static/sql-createpolicy.html Description: Domains and row level policies are similar in the definition of a constraint with a CHECK expression. There should be a mention of domains on the page `CREATE POLICY` and an explanation of the differences between domains and policies in the discussion of `Row Security Policies`. There should be a mention of policies on the page `CREATE DOMAIN`. -- Sent via pgsql-docs mailing list (pgsql-docs@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-docs
[DOCS] CREATE DOMAIN should also include an example of use with functions
The following documentation comment has been logged on the website: Page: https://www.postgresql.org/docs/9.6/static/sql-createdomain.html Description: The documentation of CREATE DOMAIN currently describes how optional constraints can be useful for the fields of a table. There is no mention of functions in this page. I have recently found two use cases for domains with functions: 1. validation of the format of user inputs (mobile phone number, email address, etc.) before any further processing in the function. 2. provide CURRENT_USER to a SECURITY DEFINER function (more details here: http://stackoverflow.com/a/42011279/207968) -- Sent via pgsql-docs mailing list (pgsql-docs@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-docs
[DOCS] SET CONSTRAINTS ALL IMMEDIATE affects SET TRANSACTION READ ONLY
The following documentation comment has been logged on the website:
Page: https://www.postgresql.org/docs/9.1/static/sql-set-constraints.html
Description:
We found that normally, if you execute SET TRANSACTION READ ONLY, it
prevents COMMIT from happening if any data has been changed in the
transaction (and we have been relying on this for safety).
However, SET CONSTRAINTS ALL IMMEDIATE causes this not to apply to any
subsequent changes. So it appears that the READ ONLY nature of the
transaction is implemented like a constraint.
This fails as expected:
BEGIN;
UPDATE foo SET contact='{"asdas": "1235435343"}'
WHERE foo.id = 1;
SET TRANSACTION READ ONLY;
COMMIT;
This passes unexpectedly:
BEGIN;
SET CONSTRAINTS ALL IMMEDIATE;
UPDATE foo SET contact='{"asdas": "1235435343"}'
WHERE foo.id = 1;
SET TRANSACTION READ ONLY;
COMMIT;
This fails as expected:
BEGIN;
SET TRANSACTION READ ONLY;
SET CONSTRAINTS ALL IMMEDIATE;
UPDATE foo SET contact='{"asdas": "1235435343"}'
WHERE foo.id = 1;
COMMIT;
--
Sent via pgsql-docs mailing list (pgsql-docs@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-docs
