On 10/16/13 2:40 PM, Robert Haas wrote:
> On Wed, Oct 16, 2013 at 1:26 PM, Josh Berkus <josh@agliodbs.com> wrote:
>> Also, as Tom pointed out, at some point we have to either say we really
>> support overloading or we don't.
>
> We clearly do support overloading. I don't think that's at issue.
> But as we all know, using it can cause formerly unambiguous queries to
> become ambiguous and stop working.
But that's not really what this is. It's one thing to be wary about
adding foo(bigint, int, smallint) when there are already three other
permutations in the system. (At least in other languages, compilers
will give you warnings or errors when this creates an ambiguity, so
there's no guessing.) But the problem here is that if there already is a
foo(type1)
then the proposal to add
foo(type2)
can always be shot down by
"But this will break foo('type1val')."
That can't be in the spirit of overloading.
The only way to fix this is that at the time when you add foo(type1) you
need to prevent people from being able to call foo('type1val') and
instead require the full syntax foo(type1 'type1val'). The only way to
do that, I think, is to add some other foo(type3) at the same time.
There is just something wrong with that.