I agree the function could be improved to deal with both old and new name existing simultaneously.
That is almost certainly the root cause, and one that I would confirm if the tester and site were currently available
tome.
Our work flow for this scenario is something like:
1. 9.6 pg_dump takes a snapshot of our 9.6 database.
2. Postgres is upgraded/freshly installed to 11.3..
3. The 9.6 database is restored using the version 11 pg_restore tool.
4. Once our application process starts up, it sees there is a patch available in it's old branch that is one greater
thenit's restored 9.6 content.
That happens to be a merge patch which resets the expectations.
It attempts to apply all patches in the new branch since the point of divergence and runs into my current issue.
It occurs to me I could simply put an exception handler in the rename column function and I would likely proceed
merrilyalong.
But curiosity is killing me and the cat. What is causing the old name to persist in the pg_attribute table after the
rename.?
Would a stale function referencing the old column name be a contributor?
Regards
Dave Day
-----Original Message-----
From: Tom Lane [mailto:tgl@sss.pgh.pa.us]
Sent: Tuesday, August 20, 2019 4:57 PM
To: Day, David <david.day@redcom.com>
Cc: Luca Ferrari <fluca1978@gmail.com>; pgsql-general@postgresql.org
Subject: Re: Rename a column if not already renamed.?
"Day, David" <david.day@redcom.com> writes:
> The error is something like column already exists and
Not sure about the workflow this function is used within, but maybe you need to consider what to do when both the old
andnew column names exist.
Because that sure sounds like what is happening.
regards, tom lane