SEO

Hello,

With all the recent discussion on contrib modules etc.. I would like to
offer the following suggestion. I am willing to do a good portion of the
work myself and I can get it done before feature freeze. I will need
help with the global make file stuff however so that is one dependency.

Add directory /modules
Modules are compiled and installed by default but not enabled.
Modules in 8.3 currently are:
pgrowlocks
pg_freespacemap (to be renameed pgfreespacemap to be consistent)
pgstattuple
pgcrypto
xml2
pgbuffercache
initagg

Requirements for /modules
Must go through normal vetting process on -hackers
Must include patches to core documentation in Docbook
Must include test cases? I don't recall if we have regress for all
contrib stuff.

Keep directory contrib
Contrib is not compiled or installed by default
Contrib in 8.3 would be:
start-scripts
pgbench (which I think really should be a foundry project)
vacuumlo (is this even required anymore?)
adminpack
btree_gist
etc...
Requirements for /contrib
Must go through normal vetting process on -hackers
Must includes README
Must include test cases? Same questions for modules


Thoughts, flames?

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

"Joshua D. Drake" <jd@commandprompt.com> writes:
> With all the recent discussion on contrib modules etc.. I would like to
> offer the following suggestion.

AFAICT you're proposing an entirely cosmetic reclassification of /contrib.
Aside from the difficulty of getting agreement on which ones should be
"in" and which "out", what does that really buy us? The thing that
would be really useful to work on is developing a concrete
representation of a "module" that pg_dump would understand, so that you
could e.g. tell it to omit btree_gist from a dump. It might be that
just segregating a contrib module into its own schema would be
sufficient, or maybe that wouldn't work well because of making people
need to deal with long search paths.

regards, tom lane

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

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

Tom Lane wrote:
> "Joshua D. Drake" <jd@commandprompt.com> writes:
>> With all the recent discussion on contrib modules etc.. I would like to
>> offer the following suggestion.
>
> AFAICT you're proposing an entirely cosmetic reclassification of /contrib.

For the most part yes. Perception is reality and all. The exception
being that modules are installed by default.

> Aside from the difficulty of getting agreement on which ones should be
> "in" and which "out", what does that really buy us?

True and I am sure that people with more time to waste than I would like
to spend days creating a thread that is 500 responses long on why their
particular module should be a module or a contrib.

> The thing that
> would be really useful to work on is developing a concrete
> representation of a "module" that pg_dump would understand, so that you
> could e.g. tell it to omit btree_gist from a dump.

I am offering what I can.

> It might be that
> just segregating a contrib module into its own schema would be
> sufficient, or maybe that wouldn't work well because of making people
> need to deal with long search paths.

I do like the contrib schema idea would could easily be melded into this
proposal. I don't like the idea that all of contrib would automatically
be included which is one of the reasons I wanted to split this up.

Sincerely,

Joshua D. Drake


>
> regards, tom lane
>


--

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

On Sat, Jan 27, 2007 at 08:59:47AM -0800, Joshua D. Drake wrote:
> Hello,
>
> With all the recent discussion on contrib modules etc.. I would like to
> offer the following suggestion. I am willing to do a good portion of the
> work myself and I can get it done before feature freeze. I will need
> help with the global make file stuff however so that is one dependency.
>
> Add directory /modules

Not so great. SQL:2003 has a special meaning for the word "module."

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 6: explain analyze is your friend

David Fetter wrote:
> On Sat, Jan 27, 2007 at 08:59:47AM -0800, Joshua D. Drake wrote:
>> Hello,
>>
>> With all the recent discussion on contrib modules etc.. I would like to
>> offer the following suggestion. I am willing to do a good portion of the
>> work myself and I can get it done before feature freeze. I will need
>> help with the global make file stuff however so that is one dependency.
>>
>> Add directory /modules
>
> Not so great. SQL:2003 has a special meaning for the word "module."

Yeah I saw mention of that in another thread, but I really didn't like
the word plugins. Do you have another thought? Extensions?

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 1: if posting/reading through Usenet, please send an appropriate
subscribe-nomail command to majordomo@postgresql.org so that your
message can get through to the mailing list cleanly

On Jan 28, 2007, at 11:25 , Joshua D. Drake wrote:

> David Fetter wrote:
>> Not so great. SQL:2003 has a special meaning for the word "module."
>
> Yeah I saw mention of that in another thread, but I really didn't like
> the word plugins. Do you have another thought? Extensions?

"Extensions" would tie in nicely with its common use in the docs,
especially wrt pgxs:

PostgreSQL can be extended by the user in many ways ...
PostgreSQL also accepts escape string constants, which are an
extension to the SQL standard
To use the infrastructure for your extension ...
Here is an example that builds an extension module ...
They test standard SQL operations as well as the extended
capabilities of PostgreSQL.

The pgxs docs do use "module" as well, but as previously mentioned
module already has a particular meaning in the spec.

Michael Glaesemann
grzm seespotcode net



---------------------------(end of broadcast)---------------------------
TIP 1: if posting/reading through Usenet, please send an appropriate
subscribe-nomail command to majordomo@postgresql.org so that your
message can get through to the mailing list cleanly

> PostgreSQL can be extended by the user in many ways ...
> PostgreSQL also accepts escape string constants, which are an extension
> to the SQL standard
> To use the infrastructure for your extension ...
> Here is an example that builds an extension module ...
> They test standard SQL operations as well as the extended capabilities
> of PostgreSQL.
>
> The pgxs docs do use "module" as well, but as previously mentioned
> module already has a particular meaning in the spec.

So what are we thinking here? Along with my suggestion of extensions /
contrib that we modify initdb to load an extensions schema with all
extensions into template1?

Sincerely,

Joshua D. Drake

>
> Michael Glaesemann
> grzm seespotcode net
>
>
>
> ---------------------------(end of broadcast)---------------------------
> TIP 1: if posting/reading through Usenet, please send an appropriate
> subscribe-nomail command to majordomo@postgresql.org so that your
> message can get through to the mailing list cleanly
>


--

=== 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 2: Don't 'kill -9' the postmaster

"Joshua D. Drake" <jd@commandprompt.com> writes:
> So what are we thinking here? Along with my suggestion of extensions /
> contrib that we modify initdb to load an extensions schema with all
> extensions into template1?

No, I don't think so. If you do that it's effectively moving all that
stuff into core, especially if you haven't provided a way to turn it off.
I don't plan to hold still for any back-door avenues to suddenly turning
large parts of contrib into core code.

regards, tom lane

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

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

Tom Lane wrote:
> "Joshua D. Drake" <jd@commandprompt.com> writes:
>> So what are we thinking here? Along with my suggestion of extensions /
>> contrib that we modify initdb to load an extensions schema with all
>> extensions into template1?
>
> No, I don't think so. If you do that it's effectively moving all that
> stuff into core, especially if you haven't provided a way to turn it off.

O.k. any thoughts there? What if we didn't make the extensions schema
PUBLIC? Meaning that explicits rights would have to be given for the
extensions to be used by anyone but a super user?

Obviously the initdb switch could also be selective:

initdb --enable-extensions

?

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 2: Don't 'kill -9' the postmaster

On 1/27/07, Joshua D. Drake <jd@commandprompt.com> wrote:
>
> Tom Lane wrote:
> > "Joshua D. Drake" <jd@commandprompt.com> writes:
> >> So what are we thinking here? Along with my suggestion of extensions /
> >> contrib that we modify initdb to load an extensions schema with all
> >> extensions into template1?
> >
> > No, I don't think so. If you do that it's effectively moving all that
> > stuff into core, especially if you haven't provided a way to turn it
> off.
>
> O.k. any thoughts there? What if we didn't make the extensions schema
> PUBLIC? Meaning that explicits rights would have to be given for the
> extensions to be used by anyone but a super user?
>
> Obviously the initdb switch could also be selective:
>
> initdb --enable-extensions
>
> ?
>
> Sincerely,
>
> Joshua D. Drake
>
>
>
I've been listening in on this discussion and it is closely tied to an
extension that I would like to try. The only thing holding me back is that
I am still far to green on the source code to actually propose the work I
would like to do.

It makes sense the you would want to include the contrib into the install,
but I agree with Tom this isn't something you would want in template1.
plpgsql is not even in template1 IIRC. It makes more sense to compile the
libraries and have an activation module that can be represented in a
pg_dump. Maybe the best way to do this would be to place the SQL that
modifies system catalog into a compiled library and call this as a
function. The function call could then be placed into the pg_dump if
needed.

Here is where this ties into what I am working on proposing. I have several
custom C functions in a library that I need in a restore/build. It seems
like at least a couple times every year a new cluster is built and the Admin
forgets to compile the custom functions. He builds the DB and then
"something doesn't work".

The basic idea of my proposal would be to have a function that checks for
the existence of C libraries. The next piece I would need would be a
mechanism for psql to halt the restore SQL script if these checks failed.
Finally I would need to add a switch to tell pg_dump to do the checks first
thereby causing the restore to fail, hopefully with a nice message that
clues the admin that something is wrong.

Yes all of this work so I don't get called after hours yet here I am working
on the fix after hours. :-)

It seems to me like this might be useful in incorporating an
extension/module/whatever into Postgres.

--
Kevin Barnard

"Great Beauty, great strength, and great Riches,
are really and truly of no great Use;
a right Heart exceeds all." -- Benjamin Franklin