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

Re: Modifying and solidifying contrib

From: "Joshua D(dot) Drake" <jd(at)commandprompt(dot)com>
To: David Fetter <david(at)fetter(dot)org>
Cc: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>, Michael Glaesemann <grzm(at)seespotcode(dot)net>, PostgreSQL-development <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: Modifying and solidifying contrib
Date: 2007-01-28 21:58:38
Message-ID: 45BD1C8E.4080909@commandprompt.com (view raw or flat)
Thread:
Lists: pgsql-hackers
>> Well to me that gets a little messy. I mean:
>>
>> pg_catalog,public,<user schemas>,xml2,ltree (just to get a could
>> functions?) etc...
> 
> Not as messy as trying to drop or re-create a package when there are
> already 500 functions in the public schema.

I am not sure I understand the correlation. I am not suggesting we
install anything into public. They would all go into a single additional
schema called extensions or some such.

>>>> Obviously the initdb switch could also be selective:
>>>>
>>>> initdb --enable-extensions
>>> If it were an initdb switch, I'd want to have something more like
>>>
>>> --enable-extension=earthdistance
>> And have to parse for each extension?
> 
> I don't see this as a big problem.

Well I am not really interesting in this. Someone else is welcome to try
that.

Sincerely,

Joshua D. Drake




-- 

      === The PostgreSQL Company: Command Prompt, Inc. ===
Sales/Support: +1.503.667.4564 || 24x7/Emergency: +1.800.492.2240
Providing the most comprehensive  PostgreSQL solutions since 1997
             http://www.commandprompt.com/

Donate to the PostgreSQL Project: http://www.postgresql.org/about/donate
PostgreSQL Replication: http://www.commandprompt.com/products/


In response to

Responses

pgsql-hackers by date

Next:From: Joshua D. DrakeDate: 2007-01-28 21:59:59
Subject: Re: Modifying and solidifying contrib
Previous:From: Andrew DunstanDate: 2007-01-28 21:52:27
Subject: Re: Modifying and solidifying contrib

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