| From: | Michael Paquier <michael(at)paquier(dot)xyz> |
|---|---|
| To: | Amit Langote <amitlangote09(at)gmail(dot)com> |
| Cc: | Alvaro Herrera <alvherre(at)2ndquadrant(dot)com>, Ashutosh Sharma <ashu(dot)coek88(at)gmail(dot)com>, PostgreSQL-development <pgsql-hackers(at)postgresql(dot)org>, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
| Subject: | Re: dropping column prevented due to inherited index |
| Date: | 2019-10-09 07:18:12 |
| Message-ID: | 20191009071812.GC21379@paquier.xyz |
| Views: | Raw Message | Whole Thread | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-hackers |
On Tue, Oct 08, 2019 at 06:25:05PM +0900, Amit Langote wrote:
> I thought about doing something like that, but wasn't sure if
> introducing that much complexity is warranted.
I looked at that. By experience, I think that it would be wiser to do
first the lookup of all the dependencies you would like to delete, and
then let the internal dependency machinery sort things out after
recursing (remember recent fixes related to ON COMMIT actions). In
order to do that, you actually just need to be careful to not trigger
the deletions as long as "recursing" is true because ATExecDropColumn
calls itself. And it is not actually as bad as I assumed, please see
the attached.
--
Michael
| Attachment | Content-Type | Size |
|---|---|---|
| ATExecDropColumn-inh-recursion-fix_v3.patch | text/x-diff | 5.8 KB |
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Christoph Berg | 2019-10-09 07:33:54 | Re: pgsql: Remove pqsignal() from libpq's official exports list. |
| Previous Message | Antonin Houska | 2019-10-09 06:57:39 | Re: Transparent Data Encryption (TDE) and encrypted files |