(unnamed)
text/html
Filename: (unnamed)
Type: text/html
Part: 0
<!DOCTYPE html PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN">
<html>
<head>
<title></title>
</head>
<body>
Tom Lane wrote:<br>
<blockquote type="cite" cite="mid:3159.1011804418@sss.pgh.pa.us">
<pre wrap="">Stephan Szabo <a class="moz-txt-link-rfc2396E" href="mailto:sszabo@megazone23.bigpanda.com"><sszabo@megazone23.bigpanda.com></a> writes:<br></pre>
<blockquote type="cite">
<pre wrap="">Wouldn't it make sense to prefer operators/functions earlier in the search<br>path for resolving ambiguity. So if you had plus(int4, int4) in my<br>schema and plus(int8, int8) in system, and they'd otherwise cause an<br>ambiguity failure for the query, use the plus(int4, int4) on mine. It<br>seems not too far from having the search path shadow later exact matches.<br></pre>
</blockquote>
<pre wrap=""><!----><br>Given the complexity of the resolution rules (cf.<br><a class="moz-txt-link-freetext" href="http://developer.postgresql.org/docs/postgres/typeconv.html">http://developer.postgresql.org/docs/postgres/typeconv.html</a>),<br>it's not clear that we can determine exactly which "later" entry ought<br>to be blamed for causing a resolution failure. I'd be interested to<br>hear Lockhart's opinion on this --- but my gut feeling is we don't<br>want to go there. The resolution rules are already complicated enough,<br>and I think layering an additional mechanism like that onto them might<br>make the behavior totally unpredictable.<br><br>Another problem is that this would probably cause earlier namespace<br>entries to be over-preferred. For example, suppose that the system<br>namespace has plus(int4,int4) and plus(int8,int8) and you choose to<br>define plus(int4,int8) locally. I believe you'd suddenly find yours<br>being used for *any* cross-datatype addit
ion, including cases that<br>had nothing obvious to do with either int4 or int8 ...<br></pre>
</blockquote>
This is a good example. The other option is to use name, arg1, arg2...
as a hunt path for function call resolution. This would depend on when datatype
promotion is occuring (i.e. int4 to int8, int8 to int4, etc... )<br>
<br>
Then you could just be really hard and say that only exact and trivial conversion
matches in user space will be used . <br>
<br>
There is no easy answer for this, but whatever rules are initiated need to
be something that someone can step through to solve w/o a machine.<br>
<br>
I do think you will ultimately need a search utility that provides 'which'
functionality. (Given my namespace, which function in what namespace is
going to be called.)<br>
<blockquote type="cite" cite="mid:3159.1011804418@sss.pgh.pa.us">
<pre wrap=""><br><br> regards, tom lane<br><br>---------------------------(end of broadcast)---------------------------<br>TIP 1: subscribe and unsubscribe commands go to <a class="moz-txt-link-abbreviated" href="mailto:majordomo@postgresql.org">majordomo@postgresql.org</a><br></pre>
</blockquote>
<br>
<br>
</body>
</html>