Re: tightening up on use of oid 0

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