Re: type conversion discussion - Mailing list pgsql-hackers

Tom Lane writes:

> Er ... weren't you just objecting to metric-based resolution on the
> grounds that it'd be unintelligible to users?

Well, since punting in the face of multiple possibilities isn't really an
improvement over that status quo, I kept looking. The key difference
between this (or similarly-minded) proposals and the context in which you
originally mentioned the metrics is that mine works at function creation
time, not at call resolution time.

A function creation is usually a well-controlled event, so an error
message along the lines of "if you create this function then you create an
ambiguity with function x because a call y could not be resolved
deterministically" is helpful. "Cannot resolve call x between y and z" at
call time is annoying (get the programer on the phone and ask him to clean
up his mess). Part of my proposal was a method for statically determining
ambiguities before it's too late.

Secondly, yes, lattices and related business are more complicated than say
a breadth-first search. But that need only be internally. Externally, it
tends to give intuitive behaviour because there is never an ambiguity,
whereas a BFS would presumably rely on the order of the arguments or other
such incidental things.

> > 3) There exists at least one function P in the equivalence class such that
> > Q <= P. Consider the set A of all functions in the equivalence class that
> > are >= Q. Since the class is a lattice, A has a (unique) greatest lower
> > bound. That's the function you call.
> 
> I don't think so.  The lattice property only says that the set A has a
> glb within the equivalence class.  AFAICT it doesn't promise that the
> glb will be >= Q, so you can't necessarily use the glb as the function
> to call.

Since all functions in A are >=Q by definition, Q is at least _a_ lower
bound on A. The glb(A) is also a lower bound on A, and since it's the
greatest it must also be >=Q.

The case where glb(A)=Q is when the call Q matches one existing signature
exactly, in that case you call that function. Otherwise the glb represents
the "next function up", and if there is an algorithm to find the glb of a
poset then there is also an algorithm to resolve function calls.


> A more general comment is that mathematical purity is only one of the
> considerations here, and not necessarily even one of the most important
> considerations ;-)

Well, at least it was fun for me to work it out. :-)

No, seriously, what are the considerations?

* ease of implementation
* efficiency
* predictability
* intuitiveness
* verifyability
* scalability
* simplicity

I think I got at least half of that covered, with no contenders yet at the
surface.


-- 
Peter Eisentraut                  Sernanders väg 10:115
peter_e@gmx.net                   75262 Uppsala
http://yi.org/peter-e/            Sweden