Re: RFD: schemas and different kinds of Postgres objects

...
> > Wouldn't it make sense to prefer operators/functions earlier in the search
> > path for resolving ambiguity. So if you had plus(int4, int4) in my
> > schema and plus(int8, int8) in system, and they'd otherwise cause an
> > ambiguity failure for the query, use the plus(int4, int4) on mine. It
> > seems not too far from having the search path shadow later exact matches.
> Given the complexity of the resolution rules (cf.
> http://developer.postgresql.org/docs/postgres/typeconv.html),
> it's not clear that we can determine exactly which "later" entry ought
> to be blamed for causing a resolution failure. I'd be interested to
> hear Lockhart's opinion on this --- but my gut feeling is we don't
> want to go there. The resolution rules are already complicated enough,
> and I think layering an additional mechanism like that onto them might
> make the behavior totally unpredictable.

(I've been following the discussion; I suspect that this part may
already have an obvious answer since "any" scoping -- equivalent to
flattening the namespace? -- may now be out of favor; I'm assuming that
we have a clearly scoped lookup scheme available).

imho there is nothing fundamentally difficult or "unpredictable" about
layering schema lookup on to the existing function resolution rules. One
might want a bit better diagnostics about *which* function was actually
chosen, but reasonable scoping and lookup rules could be constructed
which give reasonable behavior with the addition of schemas.

For example, the current function resolution rules prefer an exact
match, then start looking for approximate matches, and narrow that down
to preferring the one with the best explicit match on data types. If
more than one matches, then it rejects the query. (I've left out one or
two steps, but on the whole this is the behavior that matters.)

With schemas, one could choose to use "closest schema" as the tiebreaker
for multiple matches, but istm that an exact match should always win.

We might want to include a mechanism that *blocks* schema lookups deeper
into the search path, to allow reliable *complete replacement* of a
function. This would be a property of the function, to be set when it is
defined in the schema. So an implementer could choose to restrict
lookups explicitly if that is deemed necessary. Again, this is not a
huge complication.

It is an interesting discussion, and the fine points will not be brought
out without having lots of back-and-forth, which seems to be happening
already ;)

- Thomas