[COMMITTERS] pgsql: ALTER TABLE .. FORCE ROW LEVEL SECURITY

ALTER TABLE .. FORCE ROW LEVEL SECURITY To allow users to force RLS to always be applied, even for table owners, add ALTER TABLE .. FORCE ROW LEVEL SECURITY. row_security=off overrides FORCE ROW LEVEL SECURITY, to ensure pg_dump output is complete (by default). Also add SECURITY_NOFORCE_RLS cont

[COMMITTERS] pgsql: ALTER TABLE .. FORCE ROW LEVEL SECURITY

ALTER TABLE .. FORCE ROW LEVEL SECURITY To allow users to force RLS to always be applied, even for table owners, add ALTER TABLE .. FORCE ROW LEVEL SECURITY. row_security=off overrides FORCE ROW LEVEL SECURITY, to ensure pg_dump output is complete (by default). Also add SECURITY_NOFORCE_RLS cont

[COMMITTERS] pgsql: ALTER TABLE ... ALTER CONSTRAINT for FKs

ALTER TABLE ... ALTER CONSTRAINT for FKs Allow constraint attributes to be altered, so the default setting of NOT DEFERRABLE can be altered to DEFERRABLE and back. Review by Abhijit Menon-Sen Branch -- master Details --- http://git.postgresql.org/pg/commitdiff/f177cbfe676dc2c7ca2b206c54

[COMMITTERS] pgsql: ALTER TABLE ... ALTER CONSTRAINT for FKs

ALTER TABLE ... ALTER CONSTRAINT for FKs Allow constraint attributes to be altered, so the default setting of NOT DEFERRABLE can be altered to DEFERRABLE and back. Review by Abhijit Menon-Sen Branch -- master Details --- http://git.postgresql.org/pg/commitdiff/b577a57d4113bcbd1a7900b78b

Re: [COMMITTERS] pgsql: ALTER TABLE: skip FK validation when it's safe to do so

Alvaro Herrera writes: > Committer's note: catalog version bumped due to change of the Constraint > node. I can't actually find any way to have such a node in a stored > rule, but given that we have "out" support for them, better be safe. FYI, the easy way to determine this is to see if the node

[COMMITTERS] pgsql: ALTER TABLE: skip FK validation when it's safe to do so

ALTER TABLE: skip FK validation when it's safe to do so We already skip rewriting the table in these cases, but we still force a whole table scan to validate the data. This can be skipped, and thus we can make the whole ALTER TABLE operation just do some catalog touches instead of scanning the ta

[COMMITTERS] pgsql: ALTER TABLE sometimes takes only ShareUpdateExclusiveLock.

ALTER TABLE sometimes takes only ShareUpdateExclusiveLock. Along the way, be more consistent about the wording we use here. Branch -- master Details --- http://git.postgresql.org/gitweb?p=postgresql.git;a=commitdiff;h=7212c77d0cabcc468fec0b9cd7f2413b64b77050 Modified Files -

[COMMITTERS] pgsql: ALTER TABLE ...

Log Message: --- ALTER TABLE ... ADD/DROPS INHERIT (actually INHERIT / NO INHERIT) Open items: There were a few tangentially related issues that have come up that I think are TODOs. I'm likely to tackle one or two of these next so I'm interested in hearing feedback on them as well. . Con

[COMMITTERS] pgsql: ALTER TABLE OWNER must change the ownership of the table's

Log Message: --- ALTER TABLE OWNER must change the ownership of the table's rowtype too. This was not especially critical before, but it is now that we track ownership dependencies --- the dependency for the rowtype *must* shift to the new owner. Spotted by Bernd Helmle. Also fix a problem

[COMMITTERS] pgsql: ALTER TABLE ADD COLUMN exhibits a significant memory leak when

Log Message: --- ALTER TABLE ADD COLUMN exhibits a significant memory leak when adding a column with a default expression. In that situation, we need to rewrite the heap relation. To evaluate the new default expression, we use ExecEvalExpr(); however, this can allocate memory in the current

[COMMITTERS] pgsql: ALTER TABLE ADD COLUMN exhibits a significant memory leak when

Log Message: --- ALTER TABLE ADD COLUMN exhibits a significant memory leak when adding a column with a default expression. In that situation, we need to rewrite the heap relation. To evaluate the new default expression, we use ExecEvalExpr(); however, this can allocate memory in the current