On 1/30/07,
Andrew Dunstan <
andrew@dunslane.net> wrote:
[...]
4. visibility/searchpath issues. I don't think long search paths are a
huge issue, but I think we can make life a bit easier by tweaking
searchpath support a bit (David's clever SQL notwithstanding).
As for search_path -- is it really needed to change it? I think it'd be better to leave default search_path even if we have many extensions each sitting in its own schema. If DBA/DBD wants, he can change it himself.
The reasons to follow this way are:
1. two or more extensions might have functions with the same name (actually, that's what schemes/namespaces serve for) => we do not know which function should have higher priority (what order for schemas to choose?);
2. originally, when I've proposed to use separate schema name for each contrib module I've forgotten to mention another cause to do it -- this helps in development because everyone always knows what function is used (the code becomes a little bit larger, but understanding and code readability are improved) => so, it's better to not tweak search_path, it's better to encourage DBD to use full function names (if he wants to avoid using schema names, he can set search_path himself, resolving possible names priority issues mentioned above).
Finally, AFAIK other DBMSs use the similar approaches (provide additional extensions/packages/extensions/... using separate namespaces and do not try to avoid writing namespace in function calls).
--
Best regards,
Nikolay
