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 EXTENSI
On Fri, May 29, 2009 at 7:53 PM, Greg Stark wrote:
> On Fri, May 29, 2009 at 11:18 PM, Robert Haas 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 im
On Fri, May 29, 2009 at 11:18 PM, Robert Haas 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 search_path manag
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 5:45 PM, Greg Stark wrote:
> On Fri, May 29, 2009 at 10:26 PM, Robert Haas 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 provi
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 som
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* that
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
pg_exten
On Fri, May 29, 2009 at 10:26 PM, Robert Haas 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 get exported.
The
On Fri, May 29, 2009 at 4:49 PM, Tom Lane wrote:
> Greg Stark 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 int
Tom Lane wrote:
Greg Stark 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.
Greg Stark 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 problem with that
On Fri, May 29, 2009 at 5:23 PM, David E. Wheeler 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
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.
A
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.
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 usual
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
Tom Lane wrote:
Dimitri Fontaine 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
Dimitri Fontaine 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 practice
>> wou
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
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 *som
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
On Thursday 28 May 2009 21:38:29 Tom Lane wrote:
> Greg Stark 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 betw
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 functio
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
Hi,
Le 29 mai 09 à 02:32, Robert Haas a écrit :
On Thu, May 28, 2009 at 3:32 PM, Andrew Dunstan
wrote:
Tom Lane wrote:
Robert Haas 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
On Thu, May 28, 2009 at 3:32 PM, Andrew Dunstan wrote:
> Tom Lane wrote:
>> Robert Haas 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
On May 28, 2009, at 12:33 PM, Tom Lane wrote:
Greg Stark 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 yo
On May 28, 2009, at 12:10 PM, Robert Haas wrote:
It feels like a Java CLASSPATH,
or installing every application into /usr/local/ 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 (pgsql-hackers@postgresq
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 pg
On May 28, 2009, at 11:27 AM, Greg Stark wrote:
On Thu, May 28, 2009 at 5:30 PM, David E. Wheeler > 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
Greg Stark 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 of the
.so and you'
Tom Lane wrote:
Robert Haas 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
ob
On Thu, May 28, 2009 at 8:16 PM, Tom Lane wrote:
> Robert Haas 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 sim
Robert Haas 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 representing the mo
On Thu, May 28, 2009 at 2:27 PM, Greg Stark wrote:
> On Thu, May 28, 2009 at 5:30 PM, David E. Wheeler
> 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 fun
Josh Berkus 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
>> towards
Greg Stark 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 a
problem for peopl
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 w
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 (pgsql-hackers@postgresql
On Thu, May 28, 2009 at 5:30 PM, David E. Wheeler 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 namespace.
> PHP pr
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 everyt
On May 28, 2009, at 1:34 AM, Dimitri Fontaine wrote:
Andrew Dunstan 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
* 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 sch
* Dimitri Fontaine (dfonta...@hi-media.com) wrote:
> Andrew Dunstan 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 a
Hi,
Tom Lane writes:
> Andrew Gierth 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 p
Andrew Dunstan 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 taking that as
Robert Haas 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 application's nam
Hi all,
Seems the night has been providing lots of thoughs :)
Josh Berkus 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 be part of the
On Wed, May 27, 2009 at 10:02 PM, Josh Berkus 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 chopping
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. I
On Wed, May 27, 2009 at 9:01 PM, Josh Berkus 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
> design, or even a
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 t
Tom Lane wrote:
Josh Berkus 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 ;
Josh Berkus 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 ;-). However, I think t
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.
Eith
On May 27, 2009, at 2:14 PM, Tom Lane wrote:
Andrew Dunstan 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.
Some folks on this
lis
On Mon, May 25, 2009 at 11:16 AM, Dimitri Fontaine
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
> though.
>
[.
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 paramete
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:
http://www.pos
Josh Berkus 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 into a different
Andrew Dunstan 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 pattern:
create
Andrew Gierth 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 parameters in order to select
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
> "David" == "David E Wheeler" 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 abo
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 abou
Hi,
"David E. Wheeler" 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 other schem
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 it
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
subse
69 matches
Mail list logo
