David Fetter wrote:
On Tue, Jan 30, 2007 at 03:49:14PM -0500, Andrew Dunstan 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).


The only "clever" bit I added was the CASE statement. Credit for the
rest belongs to Andrew at Supernews.  It's not a bad thing for people
to keep around, either way. :)

I dislike on principle things that mangle the catalogs directly. As soon as I see one I think "why aren't we providing an SQL command for that?" By and large, I think users should be able to work as though the catalog were not visible, or at least not directly writable.

5. legacy support - we need an option to load existing extensions to the public schema as now, or support for aliases/synonyms (the latter might be good to have regardless).

Hrm.  This gets tricky.  When things are mandated to be in their own
namespace, they need not check what everybody else's things are doing
each time, whereas when they go into the public schema... :P


Why is it tricky? This is for legacy only, i.e. for object we know of today. Any future objects in existing extensions, or objects in new extensions, should not have this support - they should use their own namespaces, pure and simple.

Richard mentioned special testing requirements, but I don't see why we can't continue to use our standard regression mechanism.

A subdirectory in src/tests/regression for each one?


No. One of the reasons for us to maintain some standard extensions is to act as exemplars. You should be able to build, install and test an extension without having a complete source tree present. So each extension should keep its own sql and expected directory as now, I think.

I don't think it would be too much trouble to do extensions the way we
now do tables and schemas in pg_dump, i.e. with multiple possible
regular expression entries like

--include-extension=

and

--exclude-extension=

where the includes get evaluated before the excludes.



OK, as long as --exclude-extension has an "all" option, or we have a --no-extensions option also.

cheers

andrew

---------------------------(end of broadcast)---------------------------
TIP 3: Have you checked our extensive FAQ?

              http://www.postgresql.org/docs/faq

Reply via email to