Skip site navigation (1) Skip section navigation (2)

Re: Modifying and solidifying contrib

From: "Nikolay Samokhvalov" <samokhvalov(at)gmail(dot)com>
To: "Andrew Dunstan" <andrew(at)dunslane(dot)net>
Cc: "Bruce Momjian" <bruce(at)momjian(dot)us>, "Joshua D(dot) Drake" <jd(at)commandprompt(dot)com>, "Tom Lane" <tgl(at)sss(dot)pgh(dot)pa(dot)us>, "Richard Huxton" <dev(at)archonet(dot)com>, "Michael Glaesemann" <grzm(at)seespotcode(dot)net>, "David Fetter" <david(at)fetter(dot)org>, PostgreSQL-development <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: Modifying and solidifying contrib
Date: 2007-01-30 21:24:43
Message-ID: (view raw, whole thread or download thread mbox)
Lists: pgsql-hackers
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,

In response to

pgsql-hackers by date

Next:From: Tom LaneDate: 2007-01-30 21:34:17
Subject: Re: PL/pgSQL RENAME functionality in TODOs
Previous:From: Josh BerkusDate: 2007-01-30 21:22:23
Subject: Talks for OSCON? Only 5 days left!

Privacy Policy | About PostgreSQL
Copyright © 1996-2017 The PostgreSQL Global Development Group