From: Thomas Swan <tswan-lst@ics.olemiss.edu>
To: Tom Lane <tgl@sss.pgh.pa.us>
Cc: Stephan Szabo <sszabo@megazone23.bigpanda.com>
Cc: Peter Eisentraut <peter_e@gmx.net>
Cc: pgsql-hackers@postgresql.org, Fernando Nasser <fnasser@redhat.com>
Subject: Re: RFD: schemas and different kinds of Postgres objects
Date: Wed, 23 Jan 2002 15:16:20 -0600
Message-ID: <3C4F2824.90709@ics.olemiss.edu> (raw)
References: <20020123083152.W18169-100000@megazone23.bigpanda.com>
<3159.1011804418@sss.pgh.pa.us>
<!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/... 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>
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Reply to all the recipients using the --to and --cc options:
reply via email
To: pgsql-hackers@postgresql.org
Cc: tswan-lst@ics.olemiss.edu, tgl@sss.pgh.pa.us, sszabo@megazone23.bigpanda.com, peter_e@gmx.net, fnasser@redhat.com
Subject: Re: RFD: schemas and different kinds of Postgres objects
In-Reply-To: <3C4F2824.90709@ics.olemiss.edu>
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
This inbox is served by DDX for PostgreSQL; see mirroring instructions
for how to clone and mirror all data and code used for this inbox