Re: Modifying and solidifying contrib

On 1/30/07, Andrew Dunstan <andrew(at)dunslane(dot)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