From: | Bruce Momjian <bruce(at)momjian(dot)us> |
---|---|
To: | Corey Huinker <corey(dot)huinker(at)gmail(dot)com> |
Cc: | Peter Eisentraut <peter_e(at)gmx(dot)net>, Michael Paquier <michael(dot)paquier(at)gmail(dot)com>, pgsql-bugs(at)postgresql(dot)org |
Subject: | Re: BUG #13179: pg_upgrade failure. |
Date: | 2015-05-09 19:41:08 |
Message-ID: | 20150509194108.GH30684@momjian.us |
Views: | Whole Thread | Raw Message | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-bugs |
On Wed, May 6, 2015 at 02:58:01PM -0400, Corey Huinker wrote:
> Good to know about set search_path from current!
>
> However, this shows an issue: a database which appears functional to the
> customer will fail to upgrade, and the only error message in the log file
> complains of an object that does not exist, despite the same log file showing
> that it does. Customers, already frustrated, might find that error confusing,
> and might find the eventual explanation unsatisfying. After all, the database
> worked for them, and they never do the thing that will make their code break.
>
> The desired behavior would be an upgraded database that continues to have the
> problem of a function that will mal-function when a user changes their search
> path.
>
> Failing that, an improved error message would help.
>
> Alternately, a warning message at function creation time when
> ambiguously-pathed objects are referenced.
FYI, pg_upgrade is blindly calling pg_dump/pg_restore and erroring out
if there is any failure, so any fix would have to be done at that level.
--
Bruce Momjian <bruce(at)momjian(dot)us> http://momjian.us
EnterpriseDB http://enterprisedb.com
+ Everyone has their own god. +
From | Date | Subject | |
---|---|---|---|
Next Message | Thomas Munro | 2015-05-09 21:41:02 | Re: Re: BUG #12990: Missing pg_multixact/members files (appears to have wrapped, then truncated) |
Previous Message | Bruce Momjian | 2015-05-09 18:13:09 | Re: psqlodbc: HEAD fails to build with recent clang |