Re: Fix ALTER TABLE DROP EXPRESSION with inheritance hierarchy
| От | Peter Eisentraut |
|---|---|
| Тема | Re: Fix ALTER TABLE DROP EXPRESSION with inheritance hierarchy |
| Дата | |
| Msg-id | 71ab601c-14e3-4a0e-9956-1f641295a97d@eisentraut.org обсуждение исходный текст |
| Ответ на | Re: Fix ALTER TABLE DROP EXPRESSION with inheritance hierarchy (Kirill Reshke <reshkekirill@gmail.com>) |
| Ответы |
Re: Fix ALTER TABLE DROP EXPRESSION with inheritance hierarchy
|
| Список | pgsql-hackers |
On 25.08.25 15:04, Kirill Reshke wrote: > So we need to detect if the user did ALTER TABLE or ALTER TABLE ONLY. > And we have two parameters passed to ATPrepDropExpression: "recurse" > and "recursing". > First is about whether the user specified ONLY option and second is > about if we are recursing in our AT code. So maybe fix it as in > attached? 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? Some code works like that, for example ATExecDropColumn() and ATExecSetNotNull(). I probably originally adapted code from places like that. 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? I mean, there might be complex reasons, ALTER TABLE code is complicated, but I don't find this explained anywhere. If this worked more consistently, then the DROP EXPRESSION code might actually work correctly as written.
В списке pgsql-hackers по дате отправления: