On Thu, Dec 11, 2025 at 7:49 PM Dilip Kumar <[email protected]> wrote:
>
> I was considering the interdependence between the subscription and the
> conflict log table (CLT). IMHO, it would be logical to establish the
> subscription as dependent on the CLT. This way, if someone attempts to
> drop the CLT, the system would recognize the dependency of the
> subscription and prevent the drop unless the subscription is removed
> first or the CASCADE option is used.
>
> However, while investigating this, I encountered an error [1] stating
> that global objects are not supported in this context. This indicates
> that global objects cannot be made dependent on local objects.
>
What we need here is an equivalent of DEPENDENCY_INTERNAL for database
objects. For example, consider following case:
postgres=# create table t1(c1 int primary key);
CREATE TABLE
postgres=# \d+ t1
Table "public.t1"
Column | Type | Collation | Nullable | Default | Storage |
Compression | Stats target | Description
--------+---------+-----------+----------+---------+---------+-------------+--------------+-------------
c1 | integer | | not null | | plain |
| |
Indexes:
"t1_pkey" PRIMARY KEY, btree (c1)
Publications:
"pub1"
Not-null constraints:
"t1_c1_not_null" NOT NULL "c1"
Access method: heap
postgres=# drop index t1_pkey;
ERROR: cannot drop index t1_pkey because constraint t1_pkey on table
t1 requires it
HINT: You can drop constraint t1_pkey on table t1 instead.
Here, the PK index is created as part for CREATE TABLE operation and
pk_index is not allowed to be dropped independently.
> Although making an object dependent on global/shared objects is
> possible for certain types of shared objects [2], this is not our main
> objective.
>
As per my understanding from the above example, we need something like
that only for shared object subscription and (internally created)
table.
--
With Regards,
Amit Kapila.
