RE: Distinguish publication exclusions in object addresses

From: "Zhijie Hou (Fujitsu)" <houzj(dot)fnst(at)fujitsu(dot)com>
To: Amit Kapila <amit(dot)kapila16(at)gmail(dot)com>
Cc: vignesh C <vignesh21(at)gmail(dot)com>, Chao Li <li(dot)evan(dot)chao(at)gmail(dot)com>, Peter Smith <smithpb2250(at)gmail(dot)com>, shveta malik <shveta(dot)malik(at)gmail(dot)com>, Fujii Masao <masao(dot)fujii(at)gmail(dot)com>, PostgreSQL Hackers <pgsql-hackers(at)lists(dot)postgresql(dot)org>, Manuel Reyes Bravo <manuelreyesbravo(at)gmail(dot)com>
Subject: RE: Distinguish publication exclusions in object addresses
Date: 2026-09-17 09:55:16
Message-ID: TY4PR01MB177188EEABB06630EF5BC011E94B82@TY4PR01MB17718.jpnprd01.prod.outlook.com
Views: Whole Thread | Raw Message | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

Hi,

On Thursday, September 17, 2026 2:11 PM Amit Kapila <amit(dot)kapila16(at)gmail(dot)com> wrote:
> Seeing the other usage, I am thinking to fix this case for except tables unless
> some major change is required. We can consider changing REFRESH
> MATERIALIZED VIEW CONCURRENTLY separately. I have few points for the
> that patch:
>
> * The existing function
> RelationGetQualifiedRelationName()->get_qualified_objname() used
> get_namespace_name_or_temp() where as patch used
> get_namespace_name().
> That could create the problem with temp tables as follows:
>
> Before patch:
> postgres=# create publication mypub for all tables except(table mytemp);
> ERROR: cannot specify relation "pg_temp.mytemp" in the publication EXCEPT
> clause
> DETAIL: This operation is not supported for temporary tables.
>
> After patch:
> postgres=# create publication mypub for all tables except(table mytemp);
> ERROR: cannot specify relation "pg_temp_0.mytemp" in the publication
> EXCEPT clause
> DETAIL: This operation is not supported for temporary tables.

I checked the output for temporary objects a bit and found that the current
style is not consistent with other error messages and commands. For example,
other error messages output the actual schema name (pg_temp_xxx), while the
message touched in the patch reports only pg_temp.

I see this was changed since the original a49b9cf, which schema-qualified the
message. Although reporting pg_temp has some merits, it doesn't seem great to
change only one part of the error messages here. Maybe we can use pg_temp_xxx
for now and try to find a more general way to improve it later if needed.

Here are a few examples where pg_temp_XX is reported:

CREATE TEMP TABLE t(a int, b int);
CREATE STATISTICS pg_temp.s1 ON a,b FROM t;
CREATE STATISTICS pg_temp.s2 ON a,b FROM t;
ALTER STATISTICS pg_temp.s1 RENAME TO s2;
ERROR: statistics object "s2" already exists in schema "pg_temp_0"

CREATE TEXT SEARCH DICTIONARY pg_temp.d1 (TEMPLATE = simple);
CREATE TEXT SEARCH DICTIONARY pg_temp.d2 (TEMPLATE = simple);
ALTER TEXT SEARCH DICTIONARY pg_temp.d1 RENAME TO d2;
ERROR: text search dictionary "d2" already exists in schema "pg_temp_0"

postgres=# SELECT * FROM pg_identify_object('pg_class'::regclass, 'temp_tbl'::regclass, 0);
type | schema | name | identity
-------+-----------+----------+------------------
table | pg_temp_1 | temp_tbl | pg_temp.temp_tbl

postgres=# \d
List of relations
Schema | Name | Type | Owner
-----------+------+-------+-------
pg_temp_0 | test | table | houzj

select * from pg_namespace ;
16384 | pg_temp_0 | 10 |

Best Regards,
Zhijie Hou

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Yilin Zhang 2026-09-17 09:56:11 Re: Reducing relcache memory usage: deduping index shapes
Previous Message Alvaro Herrera 2026-09-17 09:53:23 Re: REPACK (CONCURRENTLY) backend waits indefinitely when decoding worker fails to start