On Wed, Jun 17, 2026 at 11:58 AM Amit Kapila <[email protected]> wrote: > > On Tue, Jun 16, 2026 at 4:12 PM Dilip Kumar <[email protected]> wrote: > > > > o ensure we are aligned, I want to clarify the current behavior before > > we decide on the next steps. Currently, view and function creation are > > both permitted for toast and conflict tables. However, there is a > > discrepancy in the schemas: view creation is blocked in the > > 'pg_conflict' and 'pg_toast' schemas, while function creation is > > allowed in both. So IIUC we need to take a call whether the function > > creation should be blocked in pg_conflict schema or not, logically we > > can say it can be blocked but we might need to discuss on this because > > it's allowed in the `pg_toast` schema. And if we are worried about > > the descripency that functions are allowed in this schema but views > > are not, I don't think we need to worry about this, this is an > > existing behaviour for toast also and if we want to can investigate as > > a separate thread and fix it for system schema al together? Am I > > missing something here? > > > > postgres[2205601]=# CREATE VIEW v2 AS select * from pg_toast.pg_toast_16412; > > CREATE VIEW > > > > postgres[2205601]=# CREATE VIEW v3 AS select * from > > pg_conflict.pg_conflict_log_16406; > > CREATE VIEW > > > > CREATE VIEW pg_toast.v5 AS select * from pg_toast.pg_toast_16412; > > ERROR: 42501: permission denied to create "pg_toast.v5" > > DETAIL: System catalog modifications are currently disallowed. > > LOCATION: heap_create, heap.c:322 > > > > postgres[2205601]=# CREATE VIEW pg_conflict.v5 AS select * from > > pg_conflict.pg_conflict_log_16406; > > ERROR: 42501: permission denied to create "pg_conflict.v5" > > DETAIL: Conflict schema modifications are currently disallowed. > > LOCATION: heap_create, heap.c:329 > > > > The one case which is not shared is allow_system_table_mods = on mode > where I think the view is allowed to create in pg_toast but not in > pg_conflict schema.
yeah, I shared this point earlier in [1]. I guess it's missed. > > > postgres[2205601]=# CREATE FUNCTION pg_conflict.get_conflict_count() > > RETURNS bigint > > LANGUAGE sql > > AS $$ > > SELECT count(*) FROM pg_conflict.pg_conflict_log_16406; > > $$; > > CREATE FUNCTION > > > > postgres[2205601]=# CREATE FUNCTION pg_toast.get_toast_count() > > RETURNS bigint > > LANGUAGE sql > > AS $$ > > SELECT count(*) FROM pg_toast.pg_toast_16412; > > $$; > > CREATE FUNCTION > > > > I think we should allow both functions and views in non-pg_conflict > schema and disallow both in pg_conflict schema. This is because there > is no use case of allowing user objects in pg_conflict schema (even > with allow_system_table_mods) and we have deliberately kept it closed > for user objects. The one minor advantage in keeping closed for user > objects is that we can avoid the risk of name collisions in > pg_conflict schema. Will this address questions/concerns raised on > this topic? I have the same opinion. Also I raised the same question about table names. The behaviour should be conssitent for tables, views. Please see my responses in [1]. Also see my comment #2 in [2] for table-creation inside CLT. [1]: https://www.postgresql.org/message-id/CAJpy0uDoa0CYWkxj52h%3DRM53acfsqjRihCfKrm8W%3DvRvHg01UA%40mail.gmail.com [2]: https://www.postgresql.org/message-id/CAJpy0uCoVPRvaAwgDz1EZww1PqHUd4B%3DS%2BF1Dh2F9kxKMpvJEw%40mail.gmail.com thanks Shveta
