Re: RFD: schemas and different kinds of Postgres objects
От | Bill Studenmund |
---|---|
Тема | Re: RFD: schemas and different kinds of Postgres objects |
Дата | |
Msg-id | Pine.NEB.4.33.0201231636150.7050-100000@vespasia.home-net.internetconnect.net обсуждение исходный текст |
Ответ на | Re: RFD: schemas and different kinds of Postgres objects (Stephan Szabo <sszabo@megazone23.bigpanda.com>) |
Ответы |
Re: RFD: schemas and different kinds of Postgres objects
Re: RFD: schemas and different kinds of Postgres objects |
Список | 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
В списке pgsql-hackers по дате отправления: