Re: [HACKERS] erroneous restore into pg_catalog schema

2013-06-11 Thread Dimitri Fontaine
Stephen Frost sfr...@snowman.net 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

Re: [HACKERS] erroneous restore into pg_catalog schema

2013-06-11 Thread Andres Freund
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,

Re: [HACKERS] erroneous restore into pg_catalog schema

2013-06-11 Thread Stephen Frost
* Dimitri Fontaine (dimi...@2ndquadrant.fr) wrote: Stephen Frost sfr...@snowman.net 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

Re: [HACKERS] erroneous restore into pg_catalog schema

2013-06-10 Thread Stephen Frost
Greg, * Greg Stark (st...@mit.edu) wrote: On Tue, May 14, 2013 at 11:59 AM, Stephen Frost sfr...@snowman.net 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

Re: [HACKERS] erroneous restore into pg_catalog schema

2013-06-10 Thread Dimitri Fontaine
Greg Stark st...@mit.edu writes: On Tue, May 14, 2013 at 11:59 AM, Stephen Frost sfr...@snowman.net 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

Re: [HACKERS] erroneous restore into pg_catalog schema

2013-06-10 Thread Greg Stark
On Mon, Jun 10, 2013 at 2:03 PM, Stephen Frost sfr...@snowman.net 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

Re: [HACKERS] erroneous restore into pg_catalog schema

2013-06-10 Thread Dimitri Fontaine
Stephen Frost sfr...@snowman.net 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

Re: [HACKERS] erroneous restore into pg_catalog schema

2013-06-10 Thread Stephen Frost
* 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 …

Re: [HACKERS] erroneous restore into pg_catalog schema

2013-06-10 Thread Stephen Frost
* 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 admins

Re: [HACKERS] erroneous restore into pg_catalog schema

2013-06-10 Thread Dimitri Fontaine
Stephen Frost sfr...@snowman.net 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).

Re: [HACKERS] erroneous restore into pg_catalog schema

2013-06-10 Thread Stephen Frost
* Dimitri Fontaine (dimi...@2ndquadrant.fr) wrote: Stephen Frost sfr...@snowman.net 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

Re: [HACKERS] erroneous restore into pg_catalog schema

2013-06-05 Thread Greg Stark
On Tue, May 14, 2013 at 11:59 AM, Stephen Frost sfr...@snowman.net 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

Re: [HACKERS] erroneous restore into pg_catalog schema

2013-06-03 Thread Heikki Linnakangas
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

Re: [HACKERS] erroneous restore into pg_catalog schema

2013-06-03 Thread Tom Lane
Heikki Linnakangas hlinnakan...@vmware.com 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

Re: [HACKERS] erroneous restore into pg_catalog schema

2013-06-03 Thread Heikki Linnakangas
On 03.06.2013 17:18, Tom Lane wrote: Heikki Linnakangashlinnakan...@vmware.com 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,

Re: [HACKERS] erroneous restore into pg_catalog schema

2013-05-14 Thread Dimitri Fontaine
Stephen Frost sfr...@snowman.net 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

Re: [HACKERS] erroneous restore into pg_catalog schema

2013-05-14 Thread Marko Kreen
On Tue, May 14, 2013 at 09:29:38AM +0200, Dimitri Fontaine wrote: Stephen Frost sfr...@snowman.net 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

Re: [HACKERS] erroneous restore into pg_catalog schema

2013-05-14 Thread Stephen Frost
* 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,

Re: [HACKERS] erroneous restore into pg_catalog schema

2013-05-14 Thread Andres Freund
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 the CREATE

Re: [HACKERS] erroneous restore into pg_catalog schema

2013-05-14 Thread Stephen Frost
* 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-

Re: [HACKERS] erroneous restore into pg_catalog schema

2013-05-13 Thread Heikki Linnakangas
On 09.05.2013 18:24, Robert Haas wrote: On Sat, May 4, 2013 at 3:59 PM, Tom Lanet...@sss.pgh.pa.us 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,

Re: [HACKERS] erroneous restore into pg_catalog schema

2013-05-13 Thread Tom Lane
Heikki Linnakangas hlinnakan...@vmware.com 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

Re: [HACKERS] erroneous restore into pg_catalog schema

2013-05-13 Thread Robert Haas
On Mon, May 13, 2013 at 11:48 AM, Tom Lane t...@sss.pgh.pa.us wrote: Heikki Linnakangas hlinnakan...@vmware.com 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

Re: [HACKERS] erroneous restore into pg_catalog schema

2013-05-13 Thread Tom Lane
Robert Haas robertmh...@gmail.com writes: On Mon, May 13, 2013 at 11:48 AM, Tom Lane t...@sss.pgh.pa.us wrote: Heikki Linnakangas hlinnakan...@vmware.com writes: Do we really want to forbid that? The only alternative I see is the one proposed in

Re: [HACKERS] erroneous restore into pg_catalog schema

2013-05-13 Thread Tom Lane
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

Re: [HACKERS] erroneous restore into pg_catalog schema

2013-05-13 Thread Robert Haas
On Mon, May 13, 2013 at 12:35 PM, Tom Lane t...@sss.pgh.pa.us 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

Re: [HACKERS] erroneous restore into pg_catalog schema

2013-05-13 Thread Andres Freund
On 2013-05-13 12:59:47 -0400, Robert Haas wrote: On Mon, May 13, 2013 at 12:35 PM, Tom Lane t...@sss.pgh.pa.us 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

Re: [HACKERS] erroneous restore into pg_catalog schema

2013-05-13 Thread Robert Haas
On Mon, May 13, 2013 at 1:03 PM, Andres Freund and...@2ndquadrant.com 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

Re: [HACKERS] erroneous restore into pg_catalog schema

2013-05-13 Thread Andres Freund
On 2013-05-13 13:04:52 -0400, Robert Haas wrote: On Mon, May 13, 2013 at 1:03 PM, Andres Freund and...@2ndquadrant.com 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

Re: [HACKERS] erroneous restore into pg_catalog schema

2013-05-13 Thread Tom Lane
Robert Haas robertmh...@gmail.com writes: On Mon, May 13, 2013 at 12:35 PM, Tom Lane t...@sss.pgh.pa.us 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

Re: [HACKERS] erroneous restore into pg_catalog schema

2013-05-13 Thread Heikki Linnakangas
On 13.05.2013 19:59, Robert Haas wrote: On Mon, May 13, 2013 at 12:35 PM, Tom Lanet...@sss.pgh.pa.us 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

Re: [HACKERS] erroneous restore into pg_catalog schema

2013-05-13 Thread Tom Lane
Robert Haas robertmh...@gmail.com writes: On Mon, May 13, 2013 at 1:03 PM, Andres Freund and...@2ndquadrant.com 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

Re: [HACKERS] erroneous restore into pg_catalog schema

2013-05-13 Thread Andres Freund
On 2013-05-13 13:40:57 -0400, Tom Lane wrote: Robert Haas robertmh...@gmail.com writes: On Mon, May 13, 2013 at 1:03 PM, Andres Freund and...@2ndquadrant.com wrote: Why don't we just prohibit deletion/modification for anything below FirstNormalObjectId instead of using the schema as a

Re: [HACKERS] erroneous restore into pg_catalog schema

2013-05-13 Thread Tom Lane
Andres Freund and...@2ndquadrant.com 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.

Re: [HACKERS] erroneous restore into pg_catalog schema

2013-05-13 Thread Andres Freund
On 2013-05-13 14:35:47 -0400, Tom Lane wrote: Andres Freund and...@2ndquadrant.com 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,

Re: [HACKERS] erroneous restore into pg_catalog schema

2013-05-13 Thread Tom Lane
Andres Freund and...@2ndquadrant.com 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

Re: [HACKERS] erroneous restore into pg_catalog schema

2013-05-13 Thread Andres Freund
On 2013-05-13 14:48:52 -0400, Tom Lane wrote: Andres Freund and...@2ndquadrant.com 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

Re: [HACKERS] erroneous restore into pg_catalog schema

2013-05-13 Thread Marko Kreen
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 no

Re: [HACKERS] erroneous restore into pg_catalog schema

2013-05-13 Thread Tom Lane
Andres Freund and...@2ndquadrant.com writes: On 2013-05-13 14:48:52 -0400, Tom Lane wrote: Andres Freund and...@2ndquadrant.com 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

Re: [HACKERS] erroneous restore into pg_catalog schema

2013-05-13 Thread Stephen Frost
* 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 to

Re: [HACKERS] erroneous restore into pg_catalog schema

2013-05-09 Thread Robert Haas
On Sat, May 4, 2013 at 3:59 PM, Tom Lane t...@sss.pgh.pa.us 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

Re: [HACKERS] erroneous restore into pg_catalog schema

2013-05-06 Thread Tom Lane
Dimitri Fontaine dimi...@2ndquadrant.fr writes: Tom Lane t...@sss.pgh.pa.us 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

Re: [HACKERS] erroneous restore into pg_catalog schema

2013-05-06 Thread Dimitri Fontaine
Tom Lane t...@sss.pgh.pa.us 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,

Re: [HACKERS] erroneous restore into pg_catalog schema

2013-05-04 Thread Tom Lane
Robert Haas robertmh...@gmail.com writes: On Wed, Apr 17, 2013 at 2:06 PM, Tom Lane t...@sss.pgh.pa.us 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

Re: [HACKERS] erroneous restore into pg_catalog schema

2013-05-04 Thread Dimitri Fontaine
Tom Lane t...@sss.pgh.pa.us 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

Re: [HACKERS] erroneous restore into pg_catalog schema

2013-04-22 Thread Robert Haas
On Wed, Apr 17, 2013 at 2:06 PM, Tom Lane t...@sss.pgh.pa.us 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

Re: [HACKERS] erroneous restore into pg_catalog schema

2013-04-17 Thread Robert Haas
On Tue, Jan 29, 2013 at 6:00 PM, Tom Lane t...@sss.pgh.pa.us wrote: Robert Haas robertmh...@gmail.com 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

Re: [HACKERS] erroneous restore into pg_catalog schema

2013-04-17 Thread Tom Lane
Robert Haas robertmh...@gmail.com writes: On Tue, Jan 29, 2013 at 6:00 PM, Tom Lane t...@sss.pgh.pa.us 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

Re: [HACKERS] erroneous restore into pg_catalog schema

2013-01-29 Thread Alvaro Herrera
Robert Haas escribió: On Tue, Jan 15, 2013 at 3:22 PM, Tom Lane t...@sss.pgh.pa.us wrote: Robert Haas robertmh...@gmail.com 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

Re: [HACKERS] erroneous restore into pg_catalog schema

2013-01-29 Thread Robert Haas
On Tue, Jan 29, 2013 at 2:30 PM, Alvaro Herrera alvhe...@2ndquadrant.com wrote: Robert Haas escribió: On Tue, Jan 15, 2013 at 3:22 PM, Tom Lane t...@sss.pgh.pa.us wrote: Robert Haas robertmh...@gmail.com writes: Or perhaps there is some other way to make sure that the user really meant it,

Re: [HACKERS] erroneous restore into pg_catalog schema

2013-01-29 Thread Tom Lane
Robert Haas robertmh...@gmail.com 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).

Re: [HACKERS] erroneous restore into pg_catalog schema

2013-01-15 Thread Robert Haas
On Sun, Jan 13, 2013 at 4:09 PM, Tom Lane t...@sss.pgh.pa.us 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

Re: [HACKERS] erroneous restore into pg_catalog schema

2013-01-15 Thread Robert Haas
On Mon, Jan 14, 2013 at 2:07 PM, Alvaro Herrera alvhe...@2ndquadrant.com wrote: Tom Lane escribió: Alvaro Herrera alvhe...@2ndquadrant.com writes: alvherre=# create extension adminpack; ERROR: permission denied for schema pg_catalog Um. I knew that that module's desire to shove stuff

Re: [HACKERS] erroneous restore into pg_catalog schema

2013-01-15 Thread Tom Lane
Robert Haas robertmh...@gmail.com 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

Re: [HACKERS] erroneous restore into pg_catalog schema

2013-01-15 Thread Robert Haas
On Tue, Jan 15, 2013 at 3:22 PM, Tom Lane t...@sss.pgh.pa.us wrote: Robert Haas robertmh...@gmail.com 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

Re: [HACKERS] erroneous restore into pg_catalog schema

2013-01-14 Thread Alvaro Herrera
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. --

Re: [HACKERS] erroneous restore into pg_catalog schema

2013-01-14 Thread Alvaro Herrera
Tom Lane escribió: Erik Rijkers e...@xs4all.nl 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 ]

Re: [HACKERS] erroneous restore into pg_catalog schema

2013-01-14 Thread Tom Lane
Alvaro Herrera alvhe...@2ndquadrant.com 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

Re: [HACKERS] erroneous restore into pg_catalog schema

2013-01-14 Thread Alvaro Herrera
Tom Lane wrote: Alvaro Herrera alvhe...@2ndquadrant.com 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

Re: [HACKERS] erroneous restore into pg_catalog schema

2013-01-14 Thread Tom Lane
Alvaro Herrera alvhe...@2ndquadrant.com 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=#

Re: [HACKERS] erroneous restore into pg_catalog schema

2013-01-14 Thread Dimitri Fontaine
Tom Lane t...@sss.pgh.pa.us 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

Re: [HACKERS] erroneous restore into pg_catalog schema

2013-01-14 Thread Alvaro Herrera
Tom Lane escribió: Alvaro Herrera alvhe...@2ndquadrant.com 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

[HACKERS] erroneous restore into pg_catalog schema

2013-01-13 Thread Erik Rijkers
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: HEAD $ cat test.sh #!/bin/sh db=backupbug; dropdb --echo $db; createdb --echo $db; echo drop schema if exists s cascade; | psql

Re: [HACKERS] erroneous restore into pg_catalog schema

2013-01-13 Thread Dimitri Fontaine
Erik Rijkers e...@xs4all.nl 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

Re: [HACKERS] erroneous restore into pg_catalog schema

2013-01-13 Thread Tom Lane
Erik Rijkers e...@xs4all.nl 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

Re: [HACKERS] erroneous restore into pg_catalog schema

2013-01-13 Thread Dimitri Fontaine
Tom Lane t...@sss.pgh.pa.us 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

Re: [HACKERS] erroneous restore into pg_catalog schema

2013-01-13 Thread Tom Lane
Dimitri Fontaine dimi...@2ndquadrant.fr writes: Tom Lane t...@sss.pgh.pa.us 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

Re: [HACKERS] erroneous restore into pg_catalog schema

2013-01-13 Thread Dimitri Fontaine
Tom Lane t...@sss.pgh.pa.us 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

Re: [HACKERS] erroneous restore into pg_catalog schema

2013-01-13 Thread Erik Rijkers
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 we

Re: [HACKERS] erroneous restore into pg_catalog schema

2013-01-13 Thread Andres Freund
On 2013-01-13 12:29:08 -0500, Tom Lane wrote: Erik Rijkers e...@xs4all.nl 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,

Re: [HACKERS] erroneous restore into pg_catalog schema

2013-01-13 Thread Tom Lane
Erik Rijkers e...@xs4all.nl 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