PostgreSQL出现ambiguous_function错误，远程帮忙排查修复的经历分享

前段时间，有个朋友火急火燎地找我，说他的网站突然出问题了，后台一直报一个叫“ambiguous_function”的错误，完全看不懂，网站的重要功能都瘫痪了，他用的数据库是PostgreSQL，自己折腾了半天也没搞定,只好搬救兵。

我让他别慌，先把完整的错误信息截图发给我，错误信息大概是这样的：ERROR: function my_function(integer) is not unique，下面还有几行小字提示：Could not choose the best candidate function. You might need to add explicit type casts.，朋友说，他只是在代码里调用了一个名为my_function的函数，并且传入了一个数字参数，这个功能以前一直好好的，最近也没动过数据库,不知道怎么就突然不行了。

看到“is not unique”和“ambiguous”（模糊不清的），我第一反应是：有重名函数，也就是说，数据库里很可能存在不止一个名叫my_function的函数，而PostgreSQL在收到调用指令时，面对多个选择，懵了，不知道到底该执行哪一个，这就好比你在一个房间里喊“小王”，结果同时有两个人回头，你如果不加上姓氏或者其他特征,就没办法指定具体要找谁。

我让朋友连接到他的PostgreSQL数据库，用\df命令（这是PostgreSQL自带的一个快捷命令，用于列出函数）查看一下所有名叫my_function的函数，果然，查询结果出来了，列表里赫然显示有两个都叫my_function的函数！

仔细一看，这两个函数的区别在于参数类型，一个是my_function(integer)，另一个是my_function(text)，也就是说，一个接受整数参数，另一个接受文本参数，朋友在代码里传的是个数字，比如my_function(123)，照理说PostgreSQL应该很聪明地匹配那个参数为整数类型的函数才对,为什么会报错呢？

这里就涉及到PostgreSQL函数重载的一个细微之处了，PostgreSQL支持函数重载，允许创建同名但参数不同的函数，在决定调用哪个函数时，它会尝试寻找一个最匹配的，如果传入的参数类型和多个函数定义的参数类型之间存在“隐式转换”关系,就可能出现无法决定的情况。

我让朋友检查一下数据库里有没有创建什么特殊的类型转换规则，他查了一圈，说没有主动创建过，那问题可能出在数据类型转换上，PostgreSQL有一个非常强大的功能叫“隐式类型转换”，它会自动尝试把数据转换成函数需要的类型，数字123既可以看作是整数（integer），也可以很容易地被转换成文本（text），这样一来，对于my_function(123)这个调用，PostgreSQL发现：既可以把它匹配到my_function(integer)，也可以先把123转换成‘123’，然后匹配到my_function(text)，由于这两种路径在PostgreSQL看来是“同等优秀”的，它就无法自动做出选择，于是抛出了“ambiguous function”错误。

为什么以前没问题呢？朋友回忆了一下，说大概一周前，他为了一个新需求，确实让另一个开发同事创建了一个新的my_function(text)函数，但当时测试过，老的功能还是好的，我推测，可能是数据库在进行某些操作（比如版本更新、数据迁移或者仅仅是统计信息更新）后，优化器对函数匹配的评估策略发生了细微变化,导致这个潜在的问题被引爆了。

问题根源找到了，解决方案就很清晰了,我们有几个选择：

1. 重命名函数：这是最根本的办法，给新创建的my_function(text)换一个不会重复的名字，一劳永逸地避免冲突，我建议他采用这种方式,因为这是最规范的实践。
2. 显式类型转换：在调用函数时，明确指定参数的类型，把调用改成my_function(123::integer)或者my_function(CAST(123 AS integer))，明确告诉数据库“我就是要用整数版本”,这样它就无需猜测了。
3. 删除重复函数：如果确认其中一个函数已经废弃不用,可以直接删除它。

朋友权衡之后，选择了第一种方案，因为他觉得保持代码的清晰最重要，他联系了那位同事，将my_function(text)重命名为my_function_v2(text)，然后更新了调用新功能的代码，之后，他再测试老的功能，错误果然消失了,一切恢复正常。

这次排查经历给我的启示是，在PostgreSQL中管理函数时，起名字一定要小心，尽量避免重名，即使参数不同，如果实在需要重名函数（即函数重载），在调用时最好能显式指定参数类型，避免依赖数据库的自动推断，这样可以提高代码的健壮性,防止在未来某个不经意的时刻掉进坑里。