>
> I don't think "all or nothing" is a good way to do this. 500
> functions in a schema called extensions isn't much more helpful than
> 500 in public. There's a reason namespaces were invented long ago,
> and this is classic use case for same.

I disagree, see my post previously about initializing the extensions
schema to not be accessible initially. It would be there, it would be
loaded, but it would take a superuser to grant ability to access functions.

This allows a clean distinction between the modules while allowing their
access on a case by case basis.

>>>>> --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.
>
> It's really not hard, even for a C n00b like me.

I didn't say it was hard. I said I wasn't interested

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/


---------------------------(end of broadcast)---------------------------
TIP 4: Have you searched our list archives?

http://archives.postgresql.org

On Sun, Jan 28, 2007 at 02:14:36PM -0800, Joshua D. Drake wrote:
> > I don't think "all or nothing" is a good way to do this. 500
> > functions in a schema called extensions isn't much more helpful
> > than 500 in public. There's a reason namespaces were invented
> > long ago, and this is classic use case for same.
>
> I disagree, see my post previously about initializing the extensions
> schema to not be accessible initially. It would be there, it would
> be loaded, but it would take a superuser to grant ability to access
> functions.
>
> This allows a clean distinction between the modules while allowing
> their access on a case by case basis.

It's 982 functions as of this writing in CVS TIP's contrib. Do you
not get how wacky it is to have that many functions, none of which
have any collision-prevention built into their install scripts, in a
flat namespace?

Then again, you started the PL/PHP project, so maybe I shouldn't ask

> >>>>> --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.
> >
> > It's really not hard, even for a C n00b like me.
>
> I didn't say it was hard. I said I wasn't interested

I think it's necessary to get each in its own schema whether we have
an initdb flag or not.

Cheers,
D
--
David Fetter <david@fetter.org> http://fetter.org/
phone: +1 415 235 3778 AIM: dfetter666
Skype: davidfetter

Remember to vote!

---------------------------(end of broadcast)---------------------------
TIP 9: In versions below 8.0, the planner will ignore your desire to
choose an index scan if your joining column's datatypes do not
match

David Fetter wrote:
> I think it's necessary to get each in its own schema whether we have
> an initdb flag or not.

In any case, the initdb flag idea is about as much a nonstarter as the
configure flag idea, for the same (packaging) reasons.

--
Peter Eisentraut
http://developer.postgresql.org/~petere/

---------------------------(end of broadcast)---------------------------
TIP 2: Don't 'kill -9' the postmaster

>>>>>>> --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.
>>> It's really not hard, even for a C n00b like me.
>> I didn't say it was hard. I said I wasn't interested
>
> I think it's necessary to get each in its own schema whether we have
> an initdb flag or not.

I can see schemas for certain ones. Tsearch (just as an example as it
appears to be going into core) but ltree?

Sincerely,

Joshua D. Drake


>
> Cheers,
> D


--

=== 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/


---------------------------(end of broadcast)---------------------------
TIP 4: Have you searched our list archives?

http://archives.postgresql.org

Peter Eisentraut wrote:
> David Fetter wrote:
>> I think it's necessary to get each in its own schema whether we have
>> an initdb flag or not.
>
> In any case, the initdb flag idea is about as much a nonstarter as the
> configure flag idea, for the same (packaging) reasons.

I don't see your point but it makes my life simpler. So do you opinions
on the schema idea?

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/


---------------------------(end of broadcast)---------------------------
TIP 7: You can help support the PostgreSQL project by donating at

http://www.postgresql.org/about/donate

David Fetter wrote:
> On Sun, Jan 28, 2007 at 02:14:36PM -0800, Joshua D. Drake wrote:
> > > I don't think "all or nothing" is a good way to do this. 500
> > > functions in a schema called extensions isn't much more helpful
> > > than 500 in public. There's a reason namespaces were invented
> > > long ago, and this is classic use case for same.
> >
> > I disagree, see my post previously about initializing the extensions
> > schema to not be accessible initially. It would be there, it would
> > be loaded, but it would take a superuser to grant ability to access
> > functions.
> >
> > This allows a clean distinction between the modules while allowing
> > their access on a case by case basis.
>
> It's 982 functions as of this writing in CVS TIP's contrib. Do you
> not get how wacky it is to have that many functions, none of which
> have any collision-prevention built into their install scripts, in a
> flat namespace?

We currently have 1695 standard functions. I don't see a problem with
putting the extensions all in one schema, but I also don't see the
point.

--
Bruce Momjian bruce@momjian.us
EnterpriseDB http://www.enterprisedb.com

+ If your life is a hard drive, Christ can be your backup. +

---------------------------(end of broadcast)---------------------------
TIP 5: don't forget to increase your free space map settings

Bruce Momjian wrote:
> David Fetter wrote:
>
>> It's 982 functions as of this writing in CVS TIP's contrib. Do you
>> not get how wacky it is to have that many functions, none of which
>> have any collision-prevention built into their install scripts, in a
>> flat namespace?
>>
>
> We currently have 1695 standard functions. I don't see a problem with
> putting the extensions all in one schema, but I also don't see the
> point.
>
>

I certainly don't see the point. But I do see a considerable point in
having extensions use their own schemas. The fact that we have 1695
standard functions means we bear the responsibility of ensuring we don't
have name clashes among them. We should encourage extension authors by
example to use the namespace facility to relieve themselves of having to
ensure they don't clash not only with the standard functions but with
other extensions. IOW we should act with respect to the namespace for
extensions we distribute just like we would reasonably expect authors of
third party extensions to behave.

For backwards compatibility, we might be well advised also to distribute
load scripts that put extension objects in the public schema as is done
now, but this should be a deprecated practice, IMNSHO.

cheers

andrew

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

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

Keep in mind all contrib loads into public, and I don't remember any
namespace conflict issues in the past.

---------------------------------------------------------------------------

Andrew Dunstan wrote:
> Bruce Momjian wrote:
> > David Fetter wrote:
> >
> >> It's 982 functions as of this writing in CVS TIP's contrib. Do you
> >> not get how wacky it is to have that many functions, none of which
> >> have any collision-prevention built into their install scripts, in a
> >> flat namespace?
> >>
> >
> > We currently have 1695 standard functions. I don't see a problem with
> > putting the extensions all in one schema, but I also don't see the
> > point.
> >
> >
>
> I certainly don't see the point. But I do see a considerable point in
> having extensions use their own schemas. The fact that we have 1695
> standard functions means we bear the responsibility of ensuring we don't
> have name clashes among them. We should encourage extension authors by
> example to use the namespace facility to relieve themselves of having to
> ensure they don't clash not only with the standard functions but with
> other extensions. IOW we should act with respect to the namespace for
> extensions we distribute just like we would reasonably expect authors of
> third party extensions to behave.
>
> For backwards compatibility, we might be well advised also to distribute
> load scripts that put extension objects in the public schema as is done
> now, but this should be a deprecated practice, IMNSHO.
>
> cheers
>
> andrew
>
> ---------------------------(end of broadcast)---------------------------
> TIP 3: Have you checked our extensive FAQ?
>
> http://www.postgresql.org/docs/faq

--
Bruce Momjian bruce@momjian.us
EnterpriseDB http://www.enterprisedb.com

+ If your life is a hard drive, Christ can be your backup. +

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

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

Bruce Momjian <bruce@momjian.us> writes:
> Keep in mind all contrib loads into public, and I don't remember any
> namespace conflict issues in the past.

(A) I'm not sure we would have heard about it, and (B) any one user is
probably only using a subset of what has been proposed to be loaded by
default, so the odds of collisions would go way up.

regards, tom lane

---------------------------(end of broadcast)---------------------------
TIP 9: In versions below 8.0, the planner will ignore your desire to
choose an index scan if your joining column's datatypes do not
match

Bruce Momjian wrote:
> Keep in mind all contrib loads into public, and I don't remember any
> namespace conflict issues in the past.
>

That is beside the point. Of course there haven't been conflicts -
precisely because a single group controls the whole lot. What I said was
that we should behave as sane third party extension authors would,
namely to use their own namespace to protect themselves from conflicts
with other unknown extensions. It's called setting a good example or
eating your own dog food.

cheers

andrew



---------------------------(end of broadcast)---------------------------
TIP 2: Don't 'kill -9' the postmaster