Re: Modifying and solidifying contrib

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