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
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,
* 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
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
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
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
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
* 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 …
* 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
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).
* 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
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
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
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
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,
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
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
* 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 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
* 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 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,
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
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
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
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
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
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
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
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
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
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
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
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
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.
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,
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
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
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
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
* 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
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
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
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,
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
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
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
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
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
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
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,
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).
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
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
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
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
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.
--
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 ]
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
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
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=#
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
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
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
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
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
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
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
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
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,
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
70 matches
Mail list logo
