While the encrypted parameter's documentation clearly states that it needs to
be set, if you are focused on the password parameter's documentation, there's
nothing to draw your attention to the fact that encrypted may also need to be
set.
Previously postgresql_user quoted user supplied identifers to create
grant statements that look like this:
GRANT SELECT on "tablename" to "user";
Which only works if the tablename is not in a namespace. If you supply
a namespaced tabelname like "report.revenue" then it creates this
incorrect statement:
GRANT SELECT on "report.revenue" to "user";
Which will not find the "revenue" table in the "report" namespace, but
will rather look for a table named "report.revenue" in the current
(default public) namespace. The correct form is:
GRANT SELECT on "report"."revenue" to "user";
This approach could have the unfortunate effect that code that
previously relied on the other behavior to grant privileges on tables
with periods in their names may now break. PostgreSQL users
typically shouldn't name tables as such, and users can still access the
old behavior and use tablenames with periods in the if they must by
supplying their own quoting.
Migrated all examples: in DOCUMENTATION=''' string to standalone EXAMPLES=''' string
Added deprecation warning to moduledev.rst and remove deprecated example from it
Fixed up a few typos and uppercased some acronyms.
add consistency to how EXAMPLES are formatted
