On 6/3/21 2:29 PM, Tom Lane wrote: > I wrote: >> Hmm, actually we could make step 2 a shade tighter: if a candidate >> routine is a function, match against proargtypes. If it's a procedure, >> match against coalesce(proallargtypes, proargtypes). If we find >> multiple matches, raise ambiguity error. > Where do we stand on this topic? > > I'm willing to have a go at implementing things that way, but > time's a-wasting. > >
So AIUI your suggestion is that ALTER/DROP ROUTINE will look for an ambiguity. If it doesn't find one it proceeds, otherwise it complains in which case the user will have to fall back to ALTER/DROP FUNCTION/PROCEDURE. Is that right? It seems a reasonable approach, and I wouldn't expect to find too many ambiguous cases in practice. cheers andrew -- Andrew Dunstan EDB: https://www.enterprisedb.com
