Re: RFD: schemas and different kinds of Postgres objects
От | Tom Lane |
---|---|
Тема | Re: RFD: schemas and different kinds of Postgres objects |
Дата | |
Msg-id | 3159.1011804418@sss.pgh.pa.us обсуждение исходный текст |
Ответ на | Re: RFD: schemas and different kinds of Postgres objects (Stephan Szabo <sszabo@megazone23.bigpanda.com>) |
Ответы |
Re: RFD: schemas and different kinds of Postgres objects
|
Список | pgsql-hackers |
Stephan Szabo <sszabo@megazone23.bigpanda.com> writes: > Wouldn't it make sense to prefer operators/functions earlier in the search > path for resolving ambiguity. So if you had plus(int4, int4) in my > schema and plus(int8, int8) in system, and they'd otherwise cause an > ambiguity failure for the query, use the plus(int4, int4) on mine. It > seems not too far from having the search path shadow later exact matches. Given the complexity of the resolution rules (cf. http://developer.postgresql.org/docs/postgres/typeconv.html), it's not clear that we can determine exactly which "later" entry ought to be blamed for causing a resolution failure. I'd be interested to hear Lockhart's opinion on this --- but my gut feeling is we don't want to go there. The resolution rules are already complicated enough, and I think layering an additional mechanism like that onto them might make the behavior totally unpredictable. Another problem is that this would probably cause earlier namespace entries to be over-preferred. For example, suppose that the system namespace has plus(int4,int4) and plus(int8,int8) and you choose to define plus(int4,int8) locally. I believe you'd suddenly find yours being used for *any* cross-datatype addition, including cases that had nothing obvious to do with either int4 or int8 ... regards, tom lane
В списке pgsql-hackers по дате отправления: