Remove the row_security=force GUC value.
authorNoah Misch <noah@leadboat.com>
Mon, 21 Sep 2015 00:45:41 +0000 (20:45 -0400)
committerNoah Misch <noah@leadboat.com>
Mon, 21 Sep 2015 00:45:41 +0000 (20:45 -0400)
commit537bd178c73b1d25938347b17e9e3e62898fc231
treeca5e94272fa4d90eec34454c83ab31d8921b8378
parent8346218c029dc0db425e3bea20033f96e1543df9
Remove the row_security=force GUC value.

Every query of a single ENABLE ROW SECURITY table has two meanings, with
the row_security GUC selecting between them.  With row_security=force
available, every function author would have been advised to either set
the GUC locally or test both meanings.  Non-compliance would have
threatened reliability and, for SECURITY DEFINER functions, security.
Authors already face an obligation to account for search_path, and we
should not mimic that example.  With this change, only BYPASSRLS roles
need exercise the aforementioned care.  Back-patch to 9.5, where the
row_security GUC was introduced.

Since this narrows the domain of pg_db_role_setting.setconfig and
pg_proc.proconfig, one might bump catversion.  A row_security=force
setting in one of those columns will elicit a clear message, so don't.
doc/src/sgml/config.sgml
doc/src/sgml/ddl.sgml
src/backend/utils/misc/guc.c
src/backend/utils/misc/rls.c
src/include/utils/plancache.h
src/include/utils/rls.h
src/test/regress/expected/rowsecurity.out
src/test/regress/sql/rowsecurity.sql