On Wed, 13 Oct 2004, Oliver Jowett wrote:
> >> Consider the case where you have two functions:
> >>
> >> foo(line)
> >> foo(box)
> >>
> >> Executing "SELECT foo(?)" via PreparedStatement will work fine if you
> >> pass a non-null PGline or PGbox argument to setObject, but if you try
> >> to setNull() then you will get ambiguity between the two functions at
> >> execution time.
>
I was expecting to see this "ERROR: function f("unknown") is not unique"
in all ambiguous situations. Your approach has the benefit of being
fail-fast as adding a new function to the database suddently can't
produce an ambiguity for Java code. I don't think it's a common
situation to have overloaded functions that get called with non-typed
nulls, so I wanted to allow it to work as usual for non-ambiguous
cases.
I was testing this out a little and this doesn't produce the error I
expected:
CREATE FUNCTION g(int) RETURNS int AS 'SELECT 1;' LANGUAGE sql;
CREATE FUNCTION g(float) RETURNS int AS 'SELECT 2;' LANGUAGE sql;
SELECT g(NULL);
Instead it returns 2 indicating the float version was called. I don't
know if this is a bug and/or oddity of the type system, but if it's the
expected behavior then I definitely agree with you.
> What is the drawback? The only case that will change is the case that is
> currently ambiguous. And there is a fairly simple mechanism for
> disambiguating it via PGobject.
The case that will change is that all the non-ambiguous cases can
no longer be called with untyped nulls:
- non ambiguous functions
- INSERT/UPDATE statements that use nulls
Kris Jurka