From: Tom Lane <tgl@sss.pgh.pa.us>
To: Julien Rouhaud <rjuju123@gmail.com>
cc: David Rowley <david.rowley@2ndquadrant.com>,
        Michael Paquier <michael@paquier.xyz>,
        Alvaro Herrera <alvherre@2ndquadrant.com>,
        Ash M <makmarath@hotmail.com>,
        PostgreSQL mailing lists <pgsql-bugs@lists.postgresql.org>
Subject: Re: BUG #15572: Misleading message reported by "Drop function
 operation" on DB with functions having same name
In-reply-to: 
 <CAOBaU_bPFBb=BA8Askv+1yvcrCFE0-zk3R8XwgbHTY4bhfy1fg@mail.gmail.com>
References: 
 <CAKJS1f9nQyOcCdjJ0HP=DCRanDLOCp7+L2QCnR2BAXM-8Zh5vw@mail.gmail.com>
 <201901071454.wxkoyoq4s5qp@alvherre.pgsql>
 <CAKJS1f9t5_Zfc7KVYmpsMjW3BqR_rXv2B3C7i7qukwdh11+yjA@mail.gmail.com>
 <19400.1546994166@sss.pgh.pa.us>
 <CAKJS1f-2-wVsN5zXaKWdp4xOUkkstnoPo0Lis6RQ=AEo3_pcig@mail.gmail.com>
 <CAKJS1f-ad5i_rtnRQiU4sE5L8M3rZT-JEz7eT9KSqPH0Z-0cPQ@mail.gmail.com>
 <CAKJS1f-6kdi2KyyCuHf4fM-Cuz4w99D1mMsOxhQEw2oaA5tW8g@mail.gmail.com>
 <13325.1549838359@sss.pgh.pa.us>
 <CAKJS1f9bAsZVodugqwAS6kSEtrOQKOEpdeBVJALR8iEZf9kHXg@mail.gmail.com>
 <20190212030927.GF1475@paquier.xyz>
 <CAKJS1f9=CdJotJBvjoQfNipPjaVXdDLN1+K-07QFehTGOYH+_g@mail.gmail.com>
 <7757.1550442703@sss.pgh.pa.us>
 <CAOBaU_bPFBb=BA8Askv+1yvcrCFE0-zk3R8XwgbHTY4bhfy1fg@mail.gmail.com>
Comments: In-reply-to Julien Rouhaud <rjuju123@gmail.com>
	message dated "Tue, 19 Feb 2019 17:00:26 +0100"
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-ID: <32560.1550594759.1@sss.pgh.pa.us>
Date: Tue, 19 Feb 2019 11:45:59 -0500
Message-ID: <32561.1550594759@sss.pgh.pa.us>
Precedence: bulk

Julien Rouhaud <rjuju123@gmail.com> writes:
> On Sun, Feb 17, 2019 at 11:31 PM Tom Lane <tgl@sss.pgh.pa.us> wrote:
>> Yeah, exactly.  Not only do I not feel a need to change this behavior
>> in the back branches, but the original patch is *also* an API change,
>> in that it changes the behavior of what appears to be a well-defined
>> boolean parameter.  The fact that none of the call sites found in
>> core today would care doesn't change that; you'd still be risking
>> breaking extensions, and/or future back-patches.

> Extensions calling those functions with old true/false values probably
> won't get any warning or error during compile.  Is is something we
> should worry about or is it enough to keep the same behavior in this
> case?

Yeah, I thought about that.  We can avoid such problems by assigning
the enum values such that 0 and 1 correspond to the old behaviors.
I didn't look to see if the proposed patch does it like that right
now, but it should be an easy fix if not.

			regards, tom lane