Added $service_reload parameter to params.pp, in order to allow
a reload of the postgresql server on OpenBSD, which apparently doesn't
have a service binary.
Define a proper SELECT statement to feed into Postgresql_psql's
`unless` parameter that checks if there are any tables in the specified
schema for which the specified role *does not* have the specified
privilege. Only then allow the GRANT statement to be executed. For
details see comments.
Note that this, too, suffers from the problem that there is no feasible
way to check if a role has ALL PRIVILEGES on a table in plain SQL. By
terrible convention the INSERT privilege represents ALL PRIVILEGES here.
This allows you to use `postgres_pqsl` commands to be run against a specified host. The ultimate goal being that you can use `puppetlabs-postsgresql` to run against remote instances, especially things such as Amazons RDS service.
This PR will be further extended to do things like allow remote `table_grant` and the like.
The PostgreSQL server's port is specified in `postgresql::server::port`, so use it in the `unless` clause of `Exec['set_postgres_postgrespw']`. Failing to do so results in repeated invocations of the exec resource during Puppet runs when the server's port is not set to the default of 5432.
On psql 8.1, `pg_catalog.shobj_description` does not exist. Also, if the
database to comment is not the current db then this warning will be
raised and the comment will not be applied: `WARNING: database comments
may only be applied to the current database`
This fix uses the pg_* databases to find the comment based on the
database oid rather than the shared object description function.
On psql 8.1, `pg_catalog.shobj_description` does not exist. Also, if the
database to comment is not the current db then this warning will be
raised and the comment will not be applied: `WARNING: database comments
may only be applied to the current database`
This fix uses the pg_* databases to find the comment based on the
database oid rather than the shared object description function.
The postgresql user is created by the server package, but this file
resource may be evaluated before the package is installed resulting in
permission failures.
It would be enabled, but it wouldn't work properly. This fixes that
issue the same way Puppet does itself; use the onestart/onestop and most
importantly in this case, the onestatus command.
By using this approach it means the Database server will actually start
whereas it would not before. It would enable, but not actually start.
onestatus means the service type gets the right response and behaves
properly.
