Re: RFD: schemas and different kinds of Postgres objects
От | Mike Mascari |
---|---|
Тема | Re: RFD: schemas and different kinds of Postgres objects |
Дата | |
Msg-id | 3C4E0EB1.1E3687FD@mascari.com обсуждение исходный текст |
Ответ на | Re: RFD: schemas and different kinds of Postgres objects (Peter Eisentraut <peter_e@gmx.net>) |
Список | pgsql-hackers |
Tom Lane wrote: > > I'm particularly troubled by the idea of trying to apply this "any" > lookup concept to resolution of overloaded operators and functions. > Suppose I have a reference func(type1,type2) that I'm trying to resolve, > and I have an inexact match (one requiring coercion) in my own schema. > Do I look to the "any" schema to see if there are better matches? > If so, what happens if the "any" schema contains multiple possibilities > with identical signatures (presumably created by different users)? ISTM > this will positively guarantee a resolution failure, since there's no > way for the resolver to prefer one over another. Thus, by creating > a "func(foo,bar)" function --- quite legally --- JRandomLuser might > break other people's formerly working queries that use other functions > named func. Although it's possible for this to happen now, it'll be > a lot more surprising if JRandomLuser thinks that his functions live > in his own private schema namespace. > So, in a nutshell, the price we pay for function overloading is the inability to have schema-specific functions. Right? Possibly why Oracle doesn't allow function overloading? As a user, I'd much rather have schema-specific functions than only global. I'm not downplaying the value of function overloading, but if I had the choice (which I guess I can't/won't), I'd choose schema-specific functions over function overloading... Mike Mascari mascarm@mascari.com
В списке pgsql-hackers по дате отправления: