| 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
| 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 |