From: Tom Lane <tgl@sss.pgh.pa.us>
To: Stephan Szabo <sszabo@megazone23.bigpanda.com>
Cc: Bill Studenmund <wrstuden@netbsd.org>
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, 30 Jan 2002 16:12:24 -0500
Message-ID: <26125.1012425144@sss.pgh.pa.us> (raw)
In-Reply-To: <20020123162426.K22713-100000@megazone23.bigpanda.com>
References: <20020123162426.K22713-100000@megazone23.bigpanda.com>
[ just catching up on this thread after a couple days thinking about
other things ]
Stephan Szabo <sszabo@megazone23.bigpanda.com> writes:
> AFAIK there's no way to specify that I want to make the function
> complex(integer) such that I can do CAST(1 as complex) but not as an
> implicit cast.
You may have forgotten that I recently suggested adding just such a
feature, ie a boolean flag on pg_proc rows to indicate whether they can
be considered for implicit casts. I think we'd agreed that it would be
a good thing to do in 7.3.
However, that doesn't bear very much on the general argument of the
thread. The bottom line is that we've put a whole lot of sweat into
developing rules for resolving ambiguous operator and function calls,
and I don't think we're going to be willing to toss all that effort into
the scrap heap. But making namespace search order the dominant factor
in choosing a function/operator (as Bill seems to want) would certainly
break all that carefully-crafted effort. If we put the system namespace
at the front of the search list then users would be unable to override
standard operators with schema-local substitutes; clearly that's no
good. But if we put it at the back, then a schema-local user operator
would dominate all system entries of the same operator name, even for
quite different types, and thereby it would break the resolution
behavior.
So I'm still of the opinion that my original suggestion is the only
workable one: collect candidates across all available namespaces,
discarding only those that are exact matches to candidates in earlier
namespaces, and then apply the existing resolution rules to the
collection. AFAICS this need not be any slower than what we do now,
if the catalog is set up so that we can collect candidates in one
indexscan without regard to namespace. The case where there actually
are any exact matches to discard should be uncommon, so we can deal with
it later on in the resolution process.
regards, tom lane
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: tgl@sss.pgh.pa.us, sszabo@megazone23.bigpanda.com, wrstuden@netbsd.org, peter_e@gmx.net, fnasser@redhat.com
Subject: Re: RFD: schemas and different kinds of Postgres objects
In-Reply-To: <26125.1012425144@sss.pgh.pa.us>
* 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