To: Stephan Szabo <sszabo@megazone23.bigpanda.com>
cc: Peter Eisentraut <peter_e@gmx.net>, pgsql-hackers@postgreSQL.org,
	Fernando Nasser <fnasser@redhat.com>
Subject: Re: RFD: schemas and different kinds of Postgres objects 
In-reply-to: <20020123083152.W18169-100000@megazone23.bigpanda.com> 
References: <20020123083152.W18169-100000@megazone23.bigpanda.com>
Comments: In-reply-to Stephan Szabo <sszabo@megazone23.bigpanda.com>
	message dated "Wed, 23 Jan 2002 08:35:47 -0800"
Date: Wed, 23 Jan 2002 11:46:58 -0500
Message-ID: <3159.1011804418@sss.pgh.pa.us>
From: Tom Lane <tgl@sss.pgh.pa.us>

Stephan Szabo <sszabo@megazone23.bigpanda.com> writes:
> 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.

Another problem is that this would probably cause earlier namespace
entries to be over-preferred.  For example, suppose that the system
namespace has plus(int4,int4) and plus(int8,int8) and you choose to
define plus(int4,int8) locally.  I believe you'd suddenly find yours
being used for *any* cross-datatype addition, including cases that
had nothing obvious to do with either int4 or int8 ...

			regards, tom lane