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).
In response to
pgsql-hackers by date
|Next:||From: Tom Lane||Date: 2007-01-30 21:34:17|
|Subject: Re: PL/pgSQL RENAME functionality in TODOs |
|Previous:||From: Josh Berkus||Date: 2007-01-30 21:22:23|
|Subject: Talks for OSCON? Only 5 days left!|