Tom Lane escribió:
An
alternative was to not have BEGIN/END but instead a GUC variable that
you can SET to the name of the extension currently being added to.
(The main advantage of that is that the state isn't hidden, but easily
checkable via existing commands.)
With the CREATE EXTENSION
Hi,
Le 29 mai 09 à 02:32, Robert Haas a écrit :
On Thu, May 28, 2009 at 3:32 PM, Andrew Dunstan
and...@dunslane.net wrote:
Tom Lane wrote:
Robert Haas robertmh...@gmail.com writes:
It also seems to me that we're getting seriously sidetracked from
the
dependency-tracking part of this
On Thursday 28 May 2009 02:57:00 Josh Berkus wrote:
Personally, if we're tracking stuff through special dependancies which
pg_dump will be aware of anyway, I don't see why extension objects
should go into a special schema.
But they clearly have to go into *some* schema, and it would add some
On Thursday 28 May 2009 15:24:21 Stephen Frost wrote:
I'm not real happy with it either. Sure, we can track module
dependencies seperately, but if we go down this route then we have to
come up with some concept of an extension namespace that different
extension use and prefix their
On Thursday 28 May 2009 21:38:29 Tom Lane wrote:
Greg Stark st...@enterprisedb.com writes:
I don't understand what storing them in different namespaces and then
putting them all in your search_path accomplishes. You end up with the
same mishmash of things in your namespace.
+1 ... naming
Hi,
Le 29 mai 09 à 12:18, Peter Eisentraut a écrit :
I think what this comes down to is that you need nested schemas and
a global
namespace rule. Then you can install things into
pg_extensions.postgis.submodule.special_type, etc. Makes sense on
paper.
[...]
(One such new insight might be
Peter Eisentraut wrote:
On Thursday 28 May 2009 02:57:00 Josh Berkus wrote:
Personally, if we're tracking stuff through special dependancies which
pg_dump will be aware of anyway, I don't see why extension objects
should go into a special schema.
But they clearly have to go into
Hi,
Le 29 mai 09 à 16:11, Andrew Dunstan a écrit :
I think almost all these difficulties could be overcome if we had
some sort of aliasing support, so that arbitrary objects in schema a
could be aliased in schema b. If that were in place, best practice
would undoubtedly be for each module
Dimitri Fontaine dfonta...@hi-media.com writes:
Le 29 mai 09 à 16:11, Andrew Dunstan a écrit :
I think almost all these difficulties could be overcome if we had
some sort of aliasing support, so that arbitrary objects in schema a
could be aliased in schema b. If that were in place, best
Tom Lane wrote:
Dimitri Fontaine dfonta...@hi-media.com writes:
Le 29 mai 09 à 16:11, Andrew Dunstan a écrit :
I think almost all these difficulties could be overcome if we had
some sort of aliasing support, so that arbitrary objects in schema a
could be aliased in schema b. If
Le 29 mai 09 à 17:12, Tom Lane a écrit :
What it sounds like to me is an amazingly complicated gadget with
absolutely no precedent of successful use anywhere. We'll spend a
year
fooling with the details of this and be no closer to actually solving
the problem at hand, namely getting a simple
On May 29, 2009, at 3:24 AM, Peter Eisentraut wrote:
Yeah, to reiterate what I posted elsewhere, perhaps it'd be a good
idea to
give up on the search path idea altogether and think more in terms
of an
import facility like Python, Java, and sometimes Perl have.
+1
Actually, Perl's is
On May 29, 2009, at 3:38 AM, Dimitri Fontaine wrote:
PS: we still have to provide users with easy tools to (dynamically)
manage search_path, don't we?
(I prefer not to start the search_path management tool ideas right
here).
Yes, we do, and that's what at least half this thread is about.
Dimitri,
We'd still need search_path in there, as Python's still using a path.
With 'default' search_path you'd have to qualify your type as
pg_extensions.postgis.submodule.special_type, with pg_extensions in
search_path the following notation would find it too:
postgis.submodule.special_type.
On Fri, May 29, 2009 at 5:23 PM, David E. Wheeler da...@kineticode.com wrote:
PS: we still have to provide users with easy tools to (dynamically) manage
search_path, don't we?
(I prefer not to start the search_path management tool ideas right here).
Yes, we do, and that's what at least half
Greg Stark st...@enterprisedb.com writes:
I'm actually not sure if we should allow extensions to be installed
into separate schemas.
It's starting to seem that best practice is to install public
functions/etc into a common schema and private objects into an
extension-specific schema. The main
Tom Lane wrote:
Greg Stark st...@enterprisedb.com writes:
I'm actually not sure if we should allow extensions to be installed
into separate schemas.
It's starting to seem that best practice is to install public
functions/etc into a common schema and private objects into an
On Fri, May 29, 2009 at 4:49 PM, Tom Lane t...@sss.pgh.pa.us wrote:
Greg Stark st...@enterprisedb.com writes:
I'm actually not sure if we should allow extensions to be installed
into separate schemas.
It's starting to seem that best practice is to install public
functions/etc into a common
On Fri, May 29, 2009 at 10:26 PM, Robert Haas robertmh...@gmail.com wrote:
This sounds quite horrid to me. The way programming languages solve
this problem is they have a flag that either makes certain names not
visible from other namespaces, or they provide explicit control over
which names
Robert,
Of course we have no notion of exporting or importing names at all.
Maybe we should. But I'm still of the opinion that this entire
discussion is a tangent.
As far as Extensions are concerned? Yes, it is.
Dimitri: I vote for you to get on with assuming everything goes into
On May 29, 2009, at 12:41 PM, Greg Stark wrote:
That said, I don't mind the idea of having a way to push things onto
search path like you often do in sh using PATH=/foo/bar:$PATH.
Yes, +1.
But I think the only reason to install something into a separate
schema is precisely if you *want*
On May 29, 2009, at 2:45 PM, Greg Stark wrote:
2) Normally programming languages do early binding so as soon as the
code is parsed references are resolved. You can't later define a new
function earlier in the search path and have it take over references
that have were previously referring to
On Fri, May 29, 2009 at 5:45 PM, Greg Stark st...@enterprisedb.com wrote:
On Fri, May 29, 2009 at 10:26 PM, Robert Haas robertmh...@gmail.com wrote:
This sounds quite horrid to me. The way programming languages solve
this problem is they have a flag that either makes certain names not
visible
On Fri, 29 May 2009, Greg Stark wrote:
The only reason people are having trouble managing their search_path is
because they're not using it as intended and putting things in lots of
different schemas that they intend to all be visible. If they put
everything they intend to be visible to users
On Fri, May 29, 2009 at 11:18 PM, Robert Haas robertmh...@gmail.com wrote:
Good point. But maybe there's some way of getting some kind of
behavior that is closer to lexical scoping/early binding? Because the
way it works right now has lousy security implications, beyond being
difficult for
On Fri, May 29, 2009 at 7:53 PM, Greg Stark st...@enterprisedb.com wrote:
On Fri, May 29, 2009 at 11:18 PM, Robert Haas robertmh...@gmail.com wrote:
Good point. But maybe there's some way of getting some kind of
behavior that is closer to lexical scoping/early binding? Because the
way it
Hi all,
Seems the night has been providing lots of thoughs :)
Josh Berkus j...@agliodbs.com writes:
Sure. I think that having better search path management would be a
wonderful thing; it would encourage people to use schema more in general.
However, that doesn't mean that I think it should
Robert Haas robertmh...@gmail.com writes:
The contents of a particular schema are more or less analagous to an
application. In most programming languages, an application informs
the system of the libraries that it needs and the system goes off and
loads the symbols in those libraries into the
Andrew Dunstan and...@dunslane.net writes:
Dimitri Fontaine wrote:
we all agree that a specific pg_extension schema is a good idea, as
soon as user is free not to use it at extension install time.
I don't think we all agree on that at all. ;-)
Ooops, my mistake, as few people where
Hi,
Tom Lane t...@sss.pgh.pa.us writes:
Andrew Gierth and...@tao11.riddles.org.uk writes:
Splitting up search_path is something I've been thinking about for a
while (and threw out on IRC as a suggestion, which is where Dimitri
got it); it was based on actual experience running an app that set
* Dimitri Fontaine (dfonta...@hi-media.com) wrote:
Andrew Dunstan and...@dunslane.net writes:
Dimitri Fontaine wrote:
we all agree that a specific pg_extension schema is a good idea, as
soon as user is free not to use it at extension install time.
I don't think we all agree on that
* Dimitri Fontaine (dfonta...@hi-media.com) wrote:
A better way to solve this is to have the database post_search_path (or
call it search_path_suffix) contain the extensions schemas. Now the
roles are set up without search_path_suffix, and it's easy to add an
extension living in its own
On May 28, 2009, at 1:34 AM, Dimitri Fontaine wrote:
Andrew Dunstan and...@dunslane.net writes:
Dimitri Fontaine wrote:
we all agree that a specific pg_extension schema is a good idea,
as
soon as user is free not to use it at extension install time.
I don't think we all agree on that
On May 28, 2009, at 1:13 AM, Dimitri Fontaine wrote:
Having all extensions live in pg_extension schema also solves the
problem in a much easier way, except for people who care about not
messing it all within a single schema (fourre-tout is the french for a
place where you put anything and
On Thu, May 28, 2009 at 5:30 PM, David E. Wheeler da...@kineticode.com wrote:
Yes, just as long as your extensions schema doesn't turn into a bricolage of
stuff. I mean, if I use a lot of extensions, it means that I end up with a
giant collection of functions and types and whatnot in this one
Dimitri Fontaine wrote:
we all agree that a specific pg_extension schema is a good idea, as
soon as user is free not to use it at extension install time.
I don't think we all agree on that at all. ;-)
cheers
andrew
--
Sent via pgsql-hackers mailing list
On 5/28/09 12:36 AM, Dimitri Fontaine wrote:
That really seems exactly to be what we're proposing with pre_ and post_
search_path components: don't change current meaning of search_path,
just give DBAs better ways to manage it. And now that you're leaning
towards a search_path suffix, don't you
Greg Stark st...@enterprisedb.com writes:
I don't understand what storing them in different namespaces and then
putting them all in your search_path accomplishes. You end up with the
same mishmash of things in your namespace.
+1 ... naming conflicts between different extensions are going to be
Josh Berkus j...@agliodbs.com writes:
On 5/28/09 12:36 AM, Dimitri Fontaine wrote:
That really seems exactly to be what we're proposing with pre_ and post_
search_path components: don't change current meaning of search_path,
just give DBAs better ways to manage it. And now that you're leaning
On Thu, May 28, 2009 at 2:27 PM, Greg Stark st...@enterprisedb.com wrote:
On Thu, May 28, 2009 at 5:30 PM, David E. Wheeler da...@kineticode.com
wrote:
Yes, just as long as your extensions schema doesn't turn into a bricolage of
stuff. I mean, if I use a lot of extensions, it means that I end
Robert Haas robertmh...@gmail.com writes:
It also seems to me that we're getting seriously sidetracked from the
dependency-tracking part of this project which seems to me to be a
much deeper and more fundamental issue.
I thought that part was a pretty simple problem, actually. Have an
object
On Thu, May 28, 2009 at 8:16 PM, Tom Lane t...@sss.pgh.pa.us wrote:
Robert Haas robertmh...@gmail.com writes:
It also seems to me that we're getting seriously sidetracked from the
dependency-tracking part of this project which seems to me to be a
much deeper and more fundamental issue.
I
Tom Lane wrote:
Robert Haas robertmh...@gmail.com writes:
It also seems to me that we're getting seriously sidetracked from the
dependency-tracking part of this project which seems to me to be a
much deeper and more fundamental issue.
I thought that part was a pretty simple problem,
Greg Stark st...@enterprisedb.com writes:
Is that really a complete answer? How do we deal with upgrading an
extension to a more recent version? What happens to objects in the
database which depend on objects from the extension?
Well, if it's only a code change then you install a newer version
On May 28, 2009, at 11:27 AM, Greg Stark wrote:
On Thu, May 28, 2009 at 5:30 PM, David E. Wheeler da...@kineticode.com
wrote:
Yes, just as long as your extensions schema doesn't turn into a
bricolage of
stuff. I mean, if I use a lot of extensions, it means that I end up
with a
giant
On May 28, 2009, at 11:38 AM, Tom Lane wrote:
I suppose there might be some use-case involving concurrent
installation
of multiple versions of the *same* extension, but I'm not sure we
should
be designing around that as a key case.
Agreed. One thing at a time.
Best,
David
--
Sent via
On May 28, 2009, at 12:10 PM, Robert Haas wrote:
It feels like a Java CLASSPATH,
or installing every application into /usr/local/application-name so
that your path has 50 bin directories in it.
+1 Yeah, that was my trouble with it.
Best,
David
--
Sent via pgsql-hackers mailing list
On May 28, 2009, at 12:33 PM, Tom Lane wrote:
Greg Stark st...@enterprisedb.com writes:
Is that really a complete answer? How do we deal with upgrading an
extension to a more recent version? What happens to objects in the
database which depend on objects from the extension?
Well, if it's
On Thu, May 28, 2009 at 3:32 PM, Andrew Dunstan and...@dunslane.net wrote:
Tom Lane wrote:
Robert Haas robertmh...@gmail.com writes:
It also seems to me that we're getting seriously sidetracked from the
dependency-tracking part of this project which seems to me to be a
much deeper and more
On May 25, 2009, at 2:16 AM, Dimitri Fontaine wrote:
Proposal: pg_extension, a new dedicated system schema for extensions
Good:
It's easy to see SQL objects (\df) of extensions (think contribs) you
installed, and as extension developpers are required to use it, you
don't have to care about
Hi,
David E. Wheeler da...@kineticode.com writes:
On May 25, 2009, at 2:16 AM, Dimitri Fontaine wrote:
Proposal: pg_extension, a new dedicated system schema for extensions
I like this, although I'd want to be able, as a user, to override that
default and tell an extension to install in some
On May 27, 2009, at 1:50 AM, Dimitri Fontaine wrote:
The moment you're adding specific schemas where to put extensions
into,
you have to adapt your search_path. Some applications already have to
manage search_path for their own needs, so we're trying to avoid
having
those people to care
David == David E Wheeler da...@kineticode.com writes:
The moment you're adding specific schemas where to put extensions
into, you have to adapt your search_path. Some applications
already have to manage search_path for their own needs, so we're
trying to avoid having those people to care
Andrew Gierth wrote:
Splitting up search_path is something I've been thinking about for a
while (and threw out on IRC as a suggestion, which is where Dimitri
got it); it was based on actual experience running an app that set the
search path in the connection parameters in order to select which
Andrew Gierth and...@tao11.riddles.org.uk writes:
Splitting up search_path is something I've been thinking about for a
while (and threw out on IRC as a suggestion, which is where Dimitri
got it); it was based on actual experience running an app that set the
search path in the connection
Andrew Dunstan and...@dunslane.net writes:
Another way of handling this might be to provide for prepending or
appending to the search path (or even for removing items from it).
I was just about to raise that as a requirement. Some folks on this
list might recognize the following coding
Josh Berkus j...@agliodbs.com writes:
Wait, I thought we'd given up on the search path model and wanted to
track extensions via dependencies. No?
I think what this discussion is about is trying to gauge just what
amount of support we could give someone who insisted on dropping each
extension
All,
Wait, I thought we'd given up on the search path model and wanted to
track extensions via dependencies. No?
--
Josh Berkus
PostgreSQL Experts Inc.
www.pgexperts.com
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
On May 27, 2009, at 1:49 PM, Andrew Gierth wrote:
Splitting up search_path is something I've been thinking about for a
while (and threw out on IRC as a suggestion, which is where Dimitri
got it); it was based on actual experience running an app that set the
search path in the connection
On Mon, May 25, 2009 at 11:16 AM, Dimitri Fontaine
dfonta...@hi-media.com wrote:
Hi,
Preliminary note: I'm using the term extension as if it's what we
already agree to call them, feel free to ignore this and use whatever
term you see fit. We'll have the naming issue tackled, please not now
On May 27, 2009, at 2:14 PM, Tom Lane wrote:
Andrew Dunstan and...@dunslane.net writes:
Another way of handling this might be to provide for prepending or
appending to the search path (or even for removing items from it).
I was just about to raise that as a requirement.
Yeah, I likes.
Tom,
I think what this discussion is about is trying to gauge just what
amount of support we could give someone who insisted on dropping each
extension into a different schema. It's not really related to how
we track which objects belong to which extension.
Really, they're on their own.
Josh Berkus j...@agliodbs.com writes:
Personally, if we're tracking stuff through special dependancies which
pg_dump will be aware of anyway, I don't see why extension objects
should go into a special schema.
Well, we could certainly take that attitude and eliminate all this
hassle ;-).
Tom Lane wrote:
Josh Berkus j...@agliodbs.com writes:
Personally, if we're tracking stuff through special dependancies which
pg_dump will be aware of anyway, I don't see why extension objects
should go into a special schema.
Well, we could certainly take that attitude and eliminate
Tom,
Well, we could certainly take that attitude and eliminate all this
hassle ;-). However, I think that more-flexible search path handling
might have other uses, so I don't see any reason not to think about it.
Sure. I think that having better search path management would be a
wonderful
On Wed, May 27, 2009 at 9:01 PM, Josh Berkus j...@agliodbs.com wrote:
Sure. I think that having better search path management would be a
wonderful thing; it would encourage people to use schema more in general.
However, that doesn't mean that I think it should be part of the extensions
Robert,
However, since we're on that tangent, I'm not completely convinced
that additional lists of search paths that get prepended or appended
to the main search path are the right way to go. It seems like that's
just chopping up the problem into smaller bits without really fixing
anything.
On Wed, May 27, 2009 at 10:02 PM, Josh Berkus j...@agliodbs.com wrote:
Robert,
However, since we're on that tangent, I'm not completely convinced
that additional lists of search paths that get prepended or appended
to the main search path are the right way to go. It seems like that's
just
Hi,
Preliminary note: I'm using the term extension as if it's what we
already agree to call them, feel free to ignore this and use whatever
term you see fit. We'll have the naming issue tackled, please not now
though.
Following-up to discussions we had at the Developer Meeting and
69 matches
Mail list logo
