Are we doing this?
---
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
On 2/6/07, Andrew Dunstan [EMAIL PROTECTED] wrote:
If the extension installs everything in dedicated namespace(s), I think
we would want to have an option to add those namespaces easily to search
paths. Right now all we can do is to set a search path. It would be
nice, for example, to have
On 2/7/07, Nikolay Samokhvalov [EMAIL PROTECTED] wrote:
I still think that separate namespaces for extensions is a good idea
while adjusting search_path is not. I've explained my POV in details
several messages ago in this thread...
Separation of extensions with fully specified names
Nikolay Samokhvalov wrote:
I still do not understand why is it so needed.
Your argument is some apps aren't able to call functions as
schemaname.functionname(arg1, arg2, ..), right?
wrong.
I still think that separate namespaces for extensions is a good idea
while adjusting search_path is
On 2/7/07, Andrew Dunstan [EMAIL PROTECTED] wrote:
Nikolay Samokhvalov wrote:
I still do not understand why is it so needed.
Your argument is some apps aren't able to call functions as
schemaname.functionname(arg1, arg2, ..), right?
wrong.
I still think that separate namespaces for
Nikolay Samokhvalov [EMAIL PROTECTED] writes:
We cannot use schema name as prefix for operator calling
You can, but it's kind of ugly:
regression=# SELECT 2 OPERATOR(pg_catalog.+) 2;
?column?
--
4
(1 row)
regards, tom lane
Jim Nasby wrote:
In addition to Martijn's tsearch case, there's also PostGIS. And I
believe this is a pretty big pain for them.
Hear hear! It would be nice to dump from an old PostgreSQL/PostGIS
combination and restore to a new version combination, without taking all
the function
On Mon, Jan 29, 2007 at 04:22:43PM -0500, Tom Lane wrote:
(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.
As a data point, some time ago (7.2
Andrew Sullivan wrote:
On Mon, Jan 29, 2007 at 04:22:43PM -0500, Tom Lane wrote:
(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.
As a data
On Tue, Feb 06, 2007 at 11:43:24AM -0500, Andrew Dunstan wrote:
Andrew Sullivan wrote:
As a data point, some time ago (7.2 days) I used to do this as a
matter of completeness, and never had a collision.
The point I at least have been trying to make is that extensions
generally (e.g.
Nikolay Samokhvalov wrote:
On 2/5/07, Andrew Dunstan [EMAIL PROTECTED] wrote:
[...]
I would suggest we start with what is (I think) simplest and clearest:
. catalog support via a simple extension-schema(s) map
. initdb installs standard extensions if it finds them, unless told
not to
.
On Feb 5, 2007, at 11:19 AM, Andrew Dunstan wrote:
Jim Nasby wrote:
There was also mention of having a means to tell pg_dump not to
dump extensions...
What's the use case for that? What will we do if there are db
objects that depend on some extensions? Given that there will be
some
Jim Nasby wrote:
There was also mention of having a means to tell pg_dump not to dump
extensions...
What's the use case for that? What will we do if there are db objects
that depend on some extensions? Given that there will be some uninstall
support, this one seems less necessary.
I
On Mon, Feb 05, 2007 at 12:19:51PM -0500, Andrew Dunstan wrote:
Jim Nasby wrote:
There was also mention of having a means to tell pg_dump not to dump
extensions...
What's the use case for that? What will we do if there are db objects
that depend on some extensions? Given that there will
Martijn van Oosterhout wrote:
On Mon, Feb 05, 2007 at 12:19:51PM -0500, Andrew Dunstan wrote:
Jim Nasby wrote:
There was also mention of having a means to tell pg_dump not to dump
extensions...
What's the use case for that? What will we do if there are db objects
that depend on
On 2/5/07, Andrew Dunstan [EMAIL PROTECTED] wrote:
[...]
I would suggest we start with what is (I think) simplest and clearest:
. catalog support via a simple extension-schema(s) map
. initdb installs standard extensions if it finds them, unless told not to
. support for adjusting search path.
There was also mention of having a means to tell pg_dump not to dump
extensions...
On Jan 30, 2007, at 2:49 PM, Andrew Dunstan wrote:
Bruce Momjian wrote:
Joshua D. Drake wrote:
This seems like a good first step in growing a packaging
infrastructure. I'd rather grow it organically than
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).
On Wed, Jan 31, 2007 at 09:31:00AM -0500, Andrew Dunstan wrote:
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
Bruce Momjian wrote:
Joshua D. Drake wrote:
This seems like a good first step in growing a packaging
infrastructure. I'd rather grow it organically than try to design it
all up front.
I am in Denver and have spotty inet access so forgive me. So where does
this above leave us? What
On 1/30/07, Andrew Dunstan [EMAIL PROTECTED] 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).
As for search_path -- is it really
On Tue, Jan 30, 2007 at 03:49:14PM -0500, Andrew Dunstan wrote:
Bruce Momjian wrote:
Joshua D. Drake wrote:
This seems like a good first step in growing a packaging
infrastructure. I'd rather grow it organically than try to design
it all up front.
I am in Denver and have spotty
On Jan 31, 2007, at 12:42 , David Fetter wrote:
On Tue, Jan 30, 2007 at 03:49:14PM -0500, Andrew Dunstan wrote:
6. they all need proper docs. READMEs and the like are nowhere
near good
enough.
Agreed. I'm thinking a new major section in the SGML docs is in order
with a subsection for
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
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
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
Bruce Momjian [EMAIL PROTECTED] 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
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
Andrew Dunstan wrote:
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
Bruce Momjian wrote:
Andrew Dunstan wrote:
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
Andrew Dunstan wrote:
Bruce Momjian wrote:
Andrew Dunstan wrote:
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 -
On Mon, Jan 29, 2007 at 04:44:44PM -0500, Andrew Dunstan wrote:
Bruce Momjian wrote:
Andrew Dunstan wrote:
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
Joshua D. Drake wrote:
Tom Lane wrote:
Joshua D. Drake [EMAIL PROTECTED] 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
Richard Huxton dev@archonet.com writes:
1. Add a new column for all system objects, separate from schema:
package.
Wouldn't it be a whole lot easier just to drive it off schema, rather
than inventing duplicative parallel infrastructure? That is, say that a
package has one or more schemas and
Tom Lane wrote:
Richard Huxton dev@archonet.com writes:
1. Add a new column for all system objects, separate from schema:
package.
Wouldn't it be a whole lot easier just to drive it off schema, rather
than inventing duplicative parallel infrastructure? That is, say that a
package has one or
Richard Huxton dev@archonet.com writes:
Tom Lane wrote:
Wouldn't it be a whole lot easier just to drive it off schema, rather
than inventing duplicative parallel infrastructure?
Four differences:
1. You couldn't have a tsearch package with functions in public. At
least not without some
Tom Lane wrote:
I agree
with having an explicit representation of a package in some new system
catalog for that purpose. That does not translate to needing to add
package hooks to every other catalog. Indirect links through schemas
seem more than sufficient.
This
This seems like a good first step in growing a packaging
infrastructure. I'd rather grow it organically than try to design it
all up front.
I am in Denver and have spotty inet access so forgive me. So where does
this above leave us? What are we doing?
Joshua D. Drake
cheers
andrew
Joshua D. Drake wrote:
This seems like a good first step in growing a packaging
infrastructure. I'd rather grow it organically than try to design it
all up front.
I am in Denver and have spotty inet access so forgive me. So where does
this above leave us? What are we doing?
I was
Kevin Barnard wrote:
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
David Fetter wrote:
On Sat, Jan 27, 2007 at 09:49:25PM -0800, Joshua D. Drake wrote:
Tom Lane wrote:
Joshua D. Drake [EMAIL PROTECTED] 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
On Sun, Jan 28, 2007 at 10:10:14AM -0800, Joshua D. Drake wrote:
David Fetter wrote:
On Sat, Jan 27, 2007 at 09:49:25PM -0800, Joshua D. Drake wrote:
Tom Lane wrote:
Joshua D. Drake [EMAIL PROTECTED] writes:
So what are we thinking here? Along with my suggestion of
extensions / contrib
Michael Glaesemann wrote:
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?
On Sun, Jan 28, 2007 at 04:52:27PM -0500, Andrew Dunstan wrote:
Michael Glaesemann wrote:
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
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
I don't mind this term, BUT, what we need to get across is not just that
these are extensions, but that they are *standard* extensions, supplied
with PostgreSQL core code and supported by the PostgreSQL core team.
This would be analogous with, say, the standard perl modules (like
On Sun, Jan 28, 2007 at 01:58:38PM -0800, Joshua D. Drake wrote:
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
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
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
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
--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
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
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
Joshua D. Drake [EMAIL PROTECTED] 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
Tom Lane wrote:
Joshua D. Drake [EMAIL PROTECTED] 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.
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
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
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
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
Joshua D. Drake [EMAIL PROTECTED] 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
Tom Lane wrote:
Joshua D. Drake [EMAIL PROTECTED] 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
On Sat, Jan 27, 2007 at 09:49:25PM -0800, Joshua D. Drake wrote:
Tom Lane wrote:
Joshua D. Drake [EMAIL PROTECTED] 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?
On 1/27/07, Joshua D. Drake [EMAIL PROTECTED] wrote:
Tom Lane wrote:
Joshua D. Drake [EMAIL PROTECTED] 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
63 matches
Mail list logo
