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
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 definitions
"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
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
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, 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
"schemana
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 supp
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 uninstal
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
. sup
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
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 p
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 d
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
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 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
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 reall
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 tr
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
> >>tweaki
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).
T
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 ea
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 D
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 reall
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
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 d
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
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 see
Richard Huxton 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 IMPORT TSEAR
Tom Lane wrote:
Richard Huxton 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 an
Richard Huxton 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 what it "owns
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
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 besid
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 th
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 cont
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.
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
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
de
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 w
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 st
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
> > >
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 poi
>>> --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 har
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/~
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
>
> 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 initi
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,,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 fu
>> 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
>
>> Well to me that gets a little messy. I mean:
>>
>> pg_catalog,public,,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 n
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 ano
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? Extens
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
> >>>
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
schem
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
Joshua D. Drake wrote:
> Add directory /modules
Moving stuff around in the source code probably won't matter much at all
since few users will actually look into the source code. What we need
is better presentation and accessibility of the installed items, for
example documentation and installa
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?
>
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 i
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
"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 int
> 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
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 t
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 feat
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
>
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
"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 b
63 matches
Mail list logo
