Re: RFD: schemas and different kinds of Postgres objects
Bill Studenmund <wrstuden@netbsd.org>
From: Bill Studenmund <wrstuden@netbsd.org>
To: Stephan Szabo <sszabo@megazone23.bigpanda.com>
Cc: Tom Lane <tgl@sss.pgh.pa.us>, Peter Eisentraut <peter_e@gmx.net>, <pgsql-hackers@postgreSQL.org>, Fernando Nasser <fnasser@redhat.com>
Date: 2002-01-24T00:47:48Z
Lists: pgsql-hackers
On Wed, 23 Jan 2002, Stephan Szabo wrote: > On Wed, 23 Jan 2002, Bill Studenmund wrote: > > > On Wed, 23 Jan 2002, Stephan Szabo wrote: > > > > Yes, you did. The documentation said that that would happen, so since you > > It doesn't currently say anything of the sort. If we made the above > behavior the standard, it would, but that's sort of circular. ;) Unless > I'm misreading the page Tom sent me to earlier, it seems to say it > prefers matches with exact types over coercions which would no longer be > true. The documentation says nothing about schemas at all now, so obviously it has to change. :-) > > made the call ambiguous, you wanted the coercion to happen. Or at least > > you weren't concerned that it might. > > I still disagree. If I make a complex number type in my schema, > I don't really intend integer+integer to convert to complex and give me a > complex answer even if I want to be able to cast integers into complex. > 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. Note: I've been talking about functions, and you're talking about operators. While operators are syntactic sugar for functions, one big difference is that you can't specify explicit schemas for operators (nor do I think you should be able to). I think exact matches for operators anywhere in the path would be better than local coercable ones. Does SQL'99 say anything about this? Take care, Bill