* Dimitri Fontaine (dimi...@2ndquadrant.fr) wrote:
> Stephen Frost writes:
> > What happens with the default settings when you try to install two
> > extensions that have overlapping function signatures..? I can't imagine
> > it 'just works'.. And then what? Is there a way that an admin can set
On 2013-06-11 10:33:29 +0200, Dimitri Fontaine wrote:
> That entirely depends on how the extension script is written. Making it
> possible to have two versions concurrently installed require a non
> trivial amount of efforts, but I don't think the extension facility gets
> in the way at all, curren
Stephen Frost writes:
> What happens with the default settings when you try to install two
> extensions that have overlapping function signatures..? I can't imagine
> it 'just works'.. And then what? Is there a way that an admin can set
> up search paths for individual users which provide the '
* Dimitri Fontaine (dimi...@2ndquadrant.fr) wrote:
> Stephen Frost writes:
> > While having one place to put everything sounds great, it doesn't do a
> > whole lot of good if you consider conflicts- either because you want
> > multiple versions available or because there just happens to be some
>
Stephen Frost writes:
> While having one place to put everything sounds great, it doesn't do a
> whole lot of good if you consider conflicts- either because you want
> multiple versions available or because there just happens to be some
> overlap in function names (or similar). There are also ext
* Greg Stark (st...@mit.edu) wrote:
> > I'd prefer that we let the
> > admins control both where extensions get installed to and what schemas
> > are added to the end of the search_path.
>
> This I object to. That's like having /usr/local/{apache,pgsql,kde,gnome}/bin.
... or it's like giving the
* Dimitri Fontaine (dimi...@2ndquadrant.fr) wrote:
> My opinion is that a pg_extension schema with a proper and well
> documented set of search_path properties would be good to have. A way to
> rename it per-database doesn't strike me as that useful as long as we
> have ALTER EXTENSION … SET SCHEMA
Stephen Frost writes:
> Having a schema that isn't pg_catalog doesn't necessairly mean we need a
> schema per extension. Just a 'pg_extensions' schema, which is added to
> search_path behind the scenes (just like pg_catalog..) would be better
> than having everything go into pg_catalog. I'd pref
On Mon, Jun 10, 2013 at 2:03 PM, Stephen Frost wrote:
> Having a schema that isn't pg_catalog doesn't necessairly mean we need a
> schema per extension. Just a 'pg_extensions' schema, which is added to
> search_path behind the scenes (just like pg_catalog..) would be better
> than having everythi
Greg Stark writes:
> On Tue, May 14, 2013 at 11:59 AM, Stephen Frost wrote:
>> For my part, I'd still prefer to have those go into a different schema
>> than into pg_catalog. Perhaps that's overkill but I really do like the
>> seperation of system tables from extensions which can be added and
>>
Greg,
* Greg Stark (st...@mit.edu) wrote:
> On Tue, May 14, 2013 at 11:59 AM, Stephen Frost wrote:
> > * Dimitri Fontaine (dimi...@2ndquadrant.fr) wrote:
> >> I'm not sure I agree with that view about pg_catalog. Sometimes we talk
> >> about moving some parts of core in pre-installed extensions i
On Tue, May 14, 2013 at 11:59 AM, Stephen Frost wrote:
> * Dimitri Fontaine (dimi...@2ndquadrant.fr) wrote:
>> I'm not sure I agree with that view about pg_catalog. Sometimes we talk
>> about moving some parts of core in pre-installed extensions instead, and
>> if we do that we will want those ext
On 03.06.2013 17:18, Tom Lane wrote:
Heikki Linnakangas writes:
In the interest of getting the release out, I've reverted commit
a475c603. We'll probably want to do something more elegant in the
future, but this will do for now.
That may be the best short-term answer, but I see no such revert
Heikki Linnakangas writes:
> In the interest of getting the release out, I've reverted commit
> a475c603. We'll probably want to do something more elegant in the
> future, but this will do for now.
That may be the best short-term answer, but I see no such revert
in the repo ...
On 14.05.2013 15:35, Stephen Frost wrote:
* Andres Freund (and...@2ndquadrant.com) wrote:
I don't disagree, but how is that relevant for fixing the issue at hand?
We still need to fix restores that currently target the wrong schema in
a backward compatible manner?
On this, I agree w/ Tom that
* Andres Freund (and...@2ndquadrant.com) wrote:
> I don't disagree, but how is that relevant for fixing the issue at hand?
> We still need to fix restores that currently target the wrong schema in
> a backward compatible manner?
On this, I agree w/ Tom that we should put that check back into place
On 2013-05-13 21:04:06 -0400, Stephen Frost wrote:
> * Marko Kreen (mark...@gmail.com) wrote:
> > On Sat, May 04, 2013 at 10:57:44PM +0200, Dimitri Fontaine wrote:
> > > Other than adminpack, I know of PGQ installing their objects in
> > > pg_catalog. They only began doing that when switching to th
* Dimitri Fontaine (dimi...@2ndquadrant.fr) wrote:
> I'm not sure I agree with that view about pg_catalog. Sometimes we talk
> about moving some parts of core in pre-installed extensions instead, and
> if we do that we will want those extensions to install themselves into
> pg_catalog.
For my part
On Tue, May 14, 2013 at 09:29:38AM +0200, Dimitri Fontaine wrote:
> Stephen Frost writes:
> > * Marko Kreen (mark...@gmail.com) wrote:
> >> On Sat, May 04, 2013 at 10:57:44PM +0200, Dimitri Fontaine wrote:
> >> > Other than adminpack, I know of PGQ installing their objects in
> >> > pg_catalog. Th
Stephen Frost writes:
> * Marko Kreen (mark...@gmail.com) wrote:
>> On Sat, May 04, 2013 at 10:57:44PM +0200, Dimitri Fontaine wrote:
>> > Other than adminpack, I know of PGQ installing their objects in
>> > pg_catalog. They only began doing that when switching to the CREATE
>> > EXTENSION facilit
* Marko Kreen (mark...@gmail.com) wrote:
> On Sat, May 04, 2013 at 10:57:44PM +0200, Dimitri Fontaine wrote:
> > Other than adminpack, I know of PGQ installing their objects in
> > pg_catalog. They only began doing that when switching to the CREATE
> > EXTENSION facility. And they set relocatable t
Andres Freund writes:
> On 2013-05-13 14:48:52 -0400, Tom Lane wrote:
>> Andres Freund writes:
>>> DROPing and recreating a new index in --single mode isn't that
>>> uncommon...
>> Surely you'd just REINDEX it instead. Moreover, if it isn't a system
>> index already, why are you doing this in -
On Sat, May 04, 2013 at 10:57:44PM +0200, Dimitri Fontaine wrote:
> Other than adminpack, I know of PGQ installing their objects in
> pg_catalog. They only began doing that when switching to the CREATE
> EXTENSION facility. And they set relocatable to false.
FYI - PgQ and related modules install n
On 2013-05-13 14:48:52 -0400, Tom Lane wrote:
> Andres Freund writes:
> > On 2013-05-13 14:35:47 -0400, Tom Lane wrote:
> >> That is, in fact, exactly what we want to do and must do during initdb.
> >> If you change anything about this code you'll break the way the
> >> post-bootstrap initdb steps
Andres Freund writes:
> On 2013-05-13 14:35:47 -0400, Tom Lane wrote:
>> That is, in fact, exactly what we want to do and must do during initdb.
>> If you change anything about this code you'll break the way the
>> post-bootstrap initdb steps assign OIDs.
> Well, then we should use some other way
On 2013-05-13 14:35:47 -0400, Tom Lane wrote:
> Andres Freund writes:
> > I think we shouldn't check IsPostmasterEnvironment here but instead
> > IsBootstrapProcessingMode() since we otherwise can generate oids below
> > FirstNormalObjectId in --single mode.
>
> That is, in fact, exactly what we
Andres Freund writes:
> I think we shouldn't check IsPostmasterEnvironment here but instead
> IsBootstrapProcessingMode() since we otherwise can generate oids below
> FirstNormalObjectId in --single mode.
That is, in fact, exactly what we want to do and must do during initdb.
If you change anythi
On 2013-05-13 13:40:57 -0400, Tom Lane wrote:
> Robert Haas writes:
> > On Mon, May 13, 2013 at 1:03 PM, Andres Freund
> > wrote:
> >> Why don't we just prohibit deletion/modification for anything below
> >> FirstNormalObjectId instead of using the schema as a restriction? Then
> >> we can allow
Robert Haas writes:
> On Mon, May 13, 2013 at 1:03 PM, Andres Freund wrote:
>> Why don't we just prohibit deletion/modification for anything below
>> FirstNormalObjectId instead of using the schema as a restriction? Then
>> we can allow creation for tables as well.
> We currently do, but that le
On 13.05.2013 19:59, Robert Haas wrote:
On Mon, May 13, 2013 at 12:35 PM, Tom Lane wrote:
I wrote:
Another way to fix that inconsistency is to consider that
allow_system_table_mods should gate table creations not just drops in
pg_catalog. I'm not real sure why this wasn't the case all along .
Robert Haas writes:
> On Mon, May 13, 2013 at 12:35 PM, Tom Lane wrote:
>> Uh, scratch that last comment: actually, allow_system_table_mods *did*
>> gate that, in every existing release. I bitched upthread about the fact
>> that this was changed in 9.3, and did not hear any very satisfactory
>>
On 2013-05-13 13:04:52 -0400, Robert Haas wrote:
> On Mon, May 13, 2013 at 1:03 PM, Andres Freund wrote:
> >> It disallowed it only for tables, and not for any other object type.
> >> I found that completely arbitrary. It's perfectly obvious that people
> >> want to be able to create objects in p
On Mon, May 13, 2013 at 1:03 PM, Andres Freund wrote:
>> It disallowed it only for tables, and not for any other object type.
>> I found that completely arbitrary. It's perfectly obvious that people
>> want to be able to create objects in pg_catalog; shall we adopt a rule
>> that you can put exte
On 2013-05-13 12:59:47 -0400, Robert Haas wrote:
> On Mon, May 13, 2013 at 12:35 PM, Tom Lane wrote:
> > I wrote:
> >> Another way to fix that inconsistency is to consider that
> >> allow_system_table_mods should gate table creations not just drops in
> >> pg_catalog. I'm not real sure why this w
On Mon, May 13, 2013 at 12:35 PM, Tom Lane wrote:
> I wrote:
>> Another way to fix that inconsistency is to consider that
>> allow_system_table_mods should gate table creations not just drops in
>> pg_catalog. I'm not real sure why this wasn't the case all along ...
>
> Uh, scratch that last comm
I wrote:
> Another way to fix that inconsistency is to consider that
> allow_system_table_mods should gate table creations not just drops in
> pg_catalog. I'm not real sure why this wasn't the case all along ...
Uh, scratch that last comment: actually, allow_system_table_mods *did*
gate that, in
Robert Haas writes:
> On Mon, May 13, 2013 at 11:48 AM, Tom Lane wrote:
>> Heikki Linnakangas writes:
>>> Do we really want to forbid that?
>> The only alternative I see is the one proposed in
>> http://www.postgresql.org/message-id/12365.1358098...@sss.pgh.pa.us:
> Let me propose another alte
On Mon, May 13, 2013 at 11:48 AM, Tom Lane wrote:
> Heikki Linnakangas writes:
>> On 09.05.2013 18:24, Robert Haas wrote:
>>> In the attached new version of the patch, I added an explicit check to
>>> prevent relocatable extensions from being created in pg_catalog.
>
>> Do we really want to forbi
Heikki Linnakangas writes:
> On 09.05.2013 18:24, Robert Haas wrote:
>> In the attached new version of the patch, I added an explicit check to
>> prevent relocatable extensions from being created in pg_catalog.
> Do we really want to forbid that?
The only alternative I see is the one proposed in
On 09.05.2013 18:24, Robert Haas wrote:
On Sat, May 4, 2013 at 3:59 PM, Tom Lane wrote:
Given the lack of any good alternative proposals, I think we should
press ahead with this approach. We still need doc updates and fixes
for the affected contrib module(s), though. Also, in view of point 2,
On Sat, May 4, 2013 at 3:59 PM, Tom Lane wrote:
> Given the lack of any good alternative proposals, I think we should
> press ahead with this approach. We still need doc updates and fixes
> for the affected contrib module(s), though. Also, in view of point 2,
> it seems like the extensions code
Tom Lane writes:
> Huh? According to the comment, at least, we don't get here for a
> relocatable extension. I don't see anything wrong with auto-creating
> the target schema for a non-relocatable extension.
I was not finding why I would trust the comment the other evening, hence
my proposal. I
Dimitri Fontaine writes:
> Tom Lane writes:
>> it seems like the extensions code should test for and reject an attempt
>> to set a relocatable extension's schema to pg_catalog. Otherwise you'd
>> be likely to get not-too-intelligible errors from the extension script.
> Reading the code now, it
Tom Lane writes:
>>> In general, we would now have a situation where relocatable extensions
>>> could never be installed into pg_catalog. That might be OK, but at
>>> least it would need to be documented.
I've been idly trying to think of examples where that would be a
problem, without success.
Robert Haas writes:
> On Wed, Apr 17, 2013 at 2:06 PM, Tom Lane wrote:
>> I think this breaks contrib/adminpack, and perhaps other extensions.
>> They'd not be hard to fix with script changes, but they'd be broken.
>>
>> In general, we would now have a situation where relocatable extensions
>> c
On Wed, Apr 17, 2013 at 2:06 PM, Tom Lane wrote:
> I think this breaks contrib/adminpack, and perhaps other extensions.
> They'd not be hard to fix with script changes, but they'd be broken.
>
> In general, we would now have a situation where relocatable extensions
> could never be installed into
Robert Haas writes:
> On Tue, Jan 29, 2013 at 6:00 PM, Tom Lane wrote:
>> I think we need to do *something* (and accordingly have added this to
>> the 9.3 open items page so we don't forget about it). Whether Robert's
>> idea is the best one probably depends in part on how clean the patch
>> tur
On Tue, Jan 29, 2013 at 6:00 PM, Tom Lane wrote:
> Robert Haas writes:
>> On Tue, Jan 29, 2013 at 2:30 PM, Alvaro Herrera
>>> Robert, are you working on this?
>
>> I wasn't, but I can, if we agree on it.
>
> I think we need to do *something* (and accordingly have added this to
> the 9.3 open item
Robert Haas writes:
> On Tue, Jan 29, 2013 at 2:30 PM, Alvaro Herrera
>> Robert, are you working on this?
> I wasn't, but I can, if we agree on it.
I think we need to do *something* (and accordingly have added this to
the 9.3 open items page so we don't forget about it). Whether Robert's
idea i
On Tue, Jan 29, 2013 at 2:30 PM, Alvaro Herrera
wrote:
> Robert Haas escribió:
>> On Tue, Jan 15, 2013 at 3:22 PM, Tom Lane wrote:
>> > Robert Haas writes:
>> >> Or perhaps there is some other way to make sure that the user "really
>> >> meant it", like refusing to create in pg_catalog unless th
Robert Haas escribió:
> On Tue, Jan 15, 2013 at 3:22 PM, Tom Lane wrote:
> > Robert Haas writes:
> >> Or perhaps there is some other way to make sure that the user "really
> >> meant it", like refusing to create in pg_catalog unless the schema
> >> name is given explicitly. I kind of like that i
On Tue, Jan 15, 2013 at 3:22 PM, Tom Lane wrote:
> Robert Haas writes:
>> Or perhaps there is some other way to make sure that the user "really
>> meant it", like refusing to create in pg_catalog unless the schema
>> name is given explicitly. I kind of like that idea, actually.
>
> That does see
Robert Haas writes:
> Or perhaps there is some other way to make sure that the user "really
> meant it", like refusing to create in pg_catalog unless the schema
> name is given explicitly. I kind of like that idea, actually.
That does seem attractive at first glance. Did you have an
implementat
On Mon, Jan 14, 2013 at 2:07 PM, Alvaro Herrera
wrote:
> Tom Lane escribió:
>> Alvaro Herrera writes:
>
>> > alvherre=# create extension adminpack;
>> > ERROR: permission denied for schema pg_catalog
>>
>> Um. I knew that that module's desire to shove stuff into pg_catalog
>> would bite us some
On Sun, Jan 13, 2013 at 4:09 PM, Tom Lane wrote:
> Right, that is the argument for ignoring missing schemas, and I think it
> is entirely sensible for *search* activities. But allowing *creation*
> to occur in an indeterminate schema is a horrid idea.
But the default search path is $user, public
Tom Lane escribió:
> Alvaro Herrera writes:
> > alvherre=# create extension adminpack;
> > ERROR: permission denied for schema pg_catalog
>
> Um. I knew that that module's desire to shove stuff into pg_catalog
> would bite us someday. But now that I think about it, I'm pretty sure
> I recall
Tom Lane writes:
> Um. I knew that that module's desire to shove stuff into pg_catalog
> would bite us someday. But now that I think about it, I'm pretty sure
> I recall discussions to the effect that there are other third-party
> modules doing similar things.
Yes, and some more have been start
Alvaro Herrera writes:
> The attached patch seems to work:
> alvherre=# create table pg_catalog.foo (a int);
> ERROR: permission denied for schema pg_catalog
> I notice that contrib/adminpack now fails, though (why doesn't this
> module have a regression test?):
> alvherre=# create extension a
Tom Lane wrote:
> Alvaro Herrera writes:
> > Tom Lane escribi�:
> >> I will bet that this is more breakage from the DDL-code refactoring that
> >> has been going on. I am getting closer and closer to wanting that
> >> reverted. KaiGai-san seems to have been throwing out lots of special
> >> case
Alvaro Herrera writes:
> Tom Lane escribió:
>> I will bet that this is more breakage from the DDL-code refactoring that
>> has been going on. I am getting closer and closer to wanting that
>> reverted. KaiGai-san seems to have been throwing out lots of special
>> cases that were there for good r
Tom Lane escribió:
> "Erik Rijkers" writes:
> > On Sun, January 13, 2013 22:09, Tom Lane wrote:
> >> BTW, although Erik claimed this behaved more sanely in 9.2, a closer
> >> look at the commit logs says that the bogus commit shipped in 9.2,
> >> so AFAICS it's broken there too.
>
> > [ not so ]
Tom Lane escribió:
> I will bet that this is more breakage from the DDL-code refactoring that
> has been going on. I am getting closer and closer to wanting that
> reverted. KaiGai-san seems to have been throwing out lots of special
> cases that were there for good reasons.
I will have a look.
"Erik Rijkers" writes:
> On Sun, January 13, 2013 22:09, Tom Lane wrote:
>> BTW, although Erik claimed this behaved more sanely in 9.2, a closer
>> look at the commit logs says that the bogus commit shipped in 9.2,
>> so AFAICS it's broken there too.
> [ not so ]
Hm, you are right, there's anoth
On 2013-01-13 12:29:08 -0500, Tom Lane wrote:
> "Erik Rijkers" writes:
> > If you dump a table with -t schema.table, and in the receiving database
> > that schema does not
> > exist, pg_restore-9.3devel will restore into the pg_catalog schema:
> > ...
> > Off course the workaround is obvious, but
On Sun, January 13, 2013 22:09, Tom Lane wrote:
>
> BTW, although Erik claimed this behaved more sanely in 9.2, a closer
> look at the commit logs says that the bogus commit shipped in 9.2,
> so AFAICS it's broken there too. But earlier releases would have
> rejected the SET as expected. I think
Tom Lane writes:
> "Break"? You can't possibly think that's a good idea.
I don't think it is. It's been used as a hack mainly before we had
per-user and per-database settings, from what I've seen.
> Right, that is the argument for ignoring missing schemas, and I think it
> is entirely sensible
Dimitri Fontaine writes:
> Tom Lane writes:
>> I think maybe what we should do is have namespace.c retain an explicit
>> notion that "the first schema listed in search_path didn't exist", and
>> then throw errors if any attempt is made to create objects without an
>> explicitly specified namespac
Tom Lane writes:
> I think maybe what we should do is have namespace.c retain an explicit
> notion that "the first schema listed in search_path didn't exist", and
> then throw errors if any attempt is made to create objects without an
> explicitly specified namespace.
I don't much like this.
S
"Erik Rijkers" writes:
> If you dump a table with -t schema.table, and in the receiving database that
> schema does not
> exist, pg_restore-9.3devel will restore into the pg_catalog schema:
> ...
> Off course the workaround is obvious, but shouldn't this be prevented from
> happening in the firs
"Erik Rijkers" writes:
> (and yes, I did restore a 65 GB table into the pg_catalog schema of a dev
> machine; how can I
> remove it? I could initdb, but it's 200+ GB; I'd rather not have to rebuild
> it)
See allow_system_table_mods
http://www.postgresql.org/docs/9.2/static/runtime-config-dev
70 matches
Mail list logo
