Re: Rename a column if not already renamed.?

From: Adrian Klaver <adrian(dot)klaver(at)aklaver(dot)com>
To: "Day, David" <david(dot)day(at)redcom(dot)com>, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
Cc: Luca Ferrari <fluca1978(at)gmail(dot)com>, "pgsql-general(at)postgresql(dot)org" <pgsql-general(at)postgresql(dot)org>
Subject: Re: Rename a column if not already renamed.?
Date: 2019-08-22 03:43:31
Message-ID: fec4a6ac-750e-6702-e864-d44ce3517d91@aklaver.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-general

On 8/21/19 11:58 AM, Day, David wrote:
> Restoring into 11.3 instance the 9.6 dump ? -> yes.
>
> For the upgrade scenario, I confirmed that both old column name and new name are in the pg_attribute table at the time the patch attempts to rename it.
> Why both is a big question.

I been playing around with that and the only way I can see it happening
is that both columns actually exist in the table.

This leads to:

1) Examine the output of the pg_dump file to see if the table comes over
with both columns.

2) Examine the table in the 11.3 instance to see if has both columns. An
indication to me that patch process is adding back the old column.

3) If neither 1) or 2) examine the patch process to see if it has both
columns in the table at some point in time and then removes the old column.

> However,
> It is easy enough to re-write the column rename function to deal with the simultaneous possibility. I will include the redefined function in the merge patch and see how it goes.
>
> I'll update the thread after some further exploration.
>
> Thanks all for your assistance.
>
>

--
Adrian Klaver
adrian(dot)klaver(at)aklaver(dot)com

In response to

Browse pgsql-general by date

  From Date Subject
Next Message Arnaud L. 2019-08-22 08:47:22 psql \copy hanging
Previous Message David G. Johnston 2019-08-22 03:14:41 Re: Importing from CSV, auto creating table?