Re: Fix ALTER TABLE DROP EXPRESSION with inheritance hierarchy

From: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
To: Peter Eisentraut <peter(at)eisentraut(dot)org>
Cc: Kirill Reshke <reshkekirill(at)gmail(dot)com>, jian he <jian(dot)universality(at)gmail(dot)com>, PostgreSQL-development <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: Fix ALTER TABLE DROP EXPRESSION with inheritance hierarchy
Date: 2025-11-04 18:16:05
Message-ID: 650085.1762280165@sss.pgh.pa.us
Views: Whole Thread | Raw Message | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

Peter Eisentraut <peter(at)eisentraut(dot)org> writes:
> I find that tablecmds.c uses these two arguments in not entirely
> consistent ways.

> I would have expected that if you write a command that is supposed to
> recurse (no ONLY) and you are some levels down into the recursing, then
> recursing=true, of course, but shouldn't recurse=true as well, to
> reflect the command that was written?

I think the intent was that

(1) recurse = true is an instruction to recurse down to any child
tables that may exist;

(2) recursing = true is a status flag saying we're already not at
the topmost parent table.

There is no situation where we'd recurse but only for a limited
number of levels, so I can't believe that recurse = false with
recursing = true is a valid state.

> But in ATPrepDropExpression(), when you're recursing, then recurse is
> always false. That is hardcoded in the ATPrepCmd() call in
> ATSimpleRecursion(). Does that make sense?

Seems wrong, but I didn't trace through the code.

regards, tom lane

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Jacob Champion 2025-11-04 18:23:16 Re: Intention to start an [oauth] "working group"
Previous Message Peter Eisentraut 2025-11-04 18:10:20 Re: Fix ALTER TABLE DROP EXPRESSION with inheritance hierarchy