On Tue, May 25, 2021 at 3:10 PM Tom Lane <t...@sss.pgh.pa.us> wrote: > No, you misunderstand my proposal. The thing that I most urgently > want to do is to prevent that situation from ever arising, by not > allowing those two procedures to coexist, just as you can't have > two functions with such signatures. > > If procedures are required to have distinct signatures when considering > input parameters only, then a fortiori they are distinct when also > considering output parameters. So my proposal cannot make a CALL > that includes output parameters ambiguous if it was not before.
Oh, OK. I'm not sure what I think about that yet. It certainly seems to make things less confusing. But on the other hand, I think that the standard - or some competing systems - may have cases where they disambiguate calls based on output arguments only. Granted, if we prohibit that now, we can always change our minds and allow it later if we are sure we've got everything figured out, whereas if we don't prohibit now, backward compatibility will make it hard to prohibit it later. But on the other hand I don't really fully understand Peter's thinking here, so I'm a little reluctant to jump to the conclusion that he's lost the way. > > I don't see any really great choice here, but in some sense your > > proposal seems like the worst of all the options. It does not reverse > > the patch's choice to treat functions and procedures differently, so > > users will still have to deal with that inconsistency. > > You're definitely confused, because reversing that choice is *exactly* > what I'm on about. The question of whether SQL-level CALL should act > differently from plpgsql CALL is pretty secondary. I understood the reverse from the first post on the thread, so perhaps it is more that your thinking has developed than that I am confused. However, it's possible that I only think that because I'm confused. -- Robert Haas EDB: http://www.enterprisedb.com
