Joe Conway m...@joeconway.com writes:
OK, done this way and committed.
Thanks,
--
Dimitri Fontaine
http://2ndQuadrant.fr PostgreSQL : Expertise, Formation et Support
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On 06/03/2013 07:57 PM, Tom Lane wrote:
I'd have put the getRules call where getEventTriggers is now, or
at least adjacent to getTriggers in one direction or the other.
I'm not sure there is anything functionally wrong with what you
have here; but
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On 06/02/2013 03:10 PM, Dimitri Fontaine wrote:
Tom Lane t...@sss.pgh.pa.us writes:
Actually, I believe the answer is just that getSchemaData() is
doing things in the wrong order:
Indeed Tom, as usual, seems to have the best correct answer :-)
Joe Conway m...@joeconway.com writes:
I was surprised by a couple of things looking at this code. First,
getRules() is written differently than other table subsidiary objects'
get functions. Secondly, I would have expected
getExtensionMembership() to be recursive -- instead it looks to only
Tom Lane t...@sss.pgh.pa.us writes:
Actually, I believe the answer is just that getSchemaData() is doing
things in the wrong order:
Each time I have to look at the pg_dump parts I discover new things.
I've been misleading Joe in telling him I though the problem must have
been in extension
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On 05/31/2013 08:46 PM, Robert Haas wrote:
On Wed, May 29, 2013 at 6:55 PM, Joe Conway m...@joeconway.com
wrote:
OK, simple enough. New patch attached. I still need to do some
testing to verify this does not break anything, but other than
that,
Joe Conway m...@joeconway.com writes:
On 05/31/2013 08:46 PM, Robert Haas wrote:
Changing SQL syntax in the back-branches isn't normally something
we do, but I confess I don't see any real reason not to do it in
this case.
That was part of my hesitation, but I don't see any better way to fix
On 2013-06-01 11:07:53 -0400, Tom Lane wrote:
Joe Conway m...@joeconway.com writes:
On 05/31/2013 08:46 PM, Robert Haas wrote:
Changing SQL syntax in the back-branches isn't normally something
we do, but I confess I don't see any real reason not to do it in
this case.
That was part of
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On 06/01/2013 08:07 AM, Tom Lane wrote:
Joe Conway m...@joeconway.com writes:
On 05/31/2013 08:46 PM, Robert Haas wrote:
Changing SQL syntax in the back-branches isn't normally
something we do, but I confess I don't see any real reason not
to do
Andres Freund and...@2ndquadrant.com writes:
On 2013-06-01 11:07:53 -0400, Tom Lane wrote:
I don't like this approach much.
1. It does nothing to fix the issue in *existing* databases, which
won't have pg_depend entries like this.
Well, you can now write an extension upgrade script that
On 2013-06-01 11:31:05 -0400, Tom Lane wrote:
Andres Freund and...@2ndquadrant.com writes:
On 2013-06-01 11:07:53 -0400, Tom Lane wrote:
I don't like this approach much.
1. It does nothing to fix the issue in *existing* databases, which
won't have pg_depend entries like this.
Well,
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On 06/01/2013 08:32 AM, Andres Freund wrote:
On 2013-06-01 11:31:05 -0400, Tom Lane wrote:
But in any case, making rules act differently from other table
properties for this purpose seems seriously wrong.
What's your proposal to fix this
Joe Conway m...@joeconway.com writes:
I can look at having pg_dump ignore these entries, but I suspect that
will be quite a bit more invasive.
Actually, I believe the answer is just that getSchemaData() is doing
things in the wrong order:
if (g_verbose)
write_msg(NULL, reading
I wrote:
Actually, I believe the answer is just that getSchemaData() is doing
things in the wrong order:
BTW, I'm inclined to think it's also wrong that the getEventTriggers()
call was just added at the end; those things are certainly not table
subsidiary objects. I don't know if we allow
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On 06/01/2013 09:39 AM, Tom Lane wrote:
I wrote:
Actually, I believe the answer is just that getSchemaData() is
doing things in the wrong order:
BTW, I'm inclined to think it's also wrong that the
getEventTriggers() call was just added at the
On Wed, May 29, 2013 at 6:55 PM, Joe Conway m...@joeconway.com wrote:
OK, simple enough. New patch attached. I still need to do some
testing to verify this does not break anything, but other than
that, any complaints (including the notion of backpatching this
back to 9.1)?
Here's a cleaned
Joe Conway m...@joeconway.com writes:
Here's a cleaned up version, which also includes documentation. I'll
commit back to 9.1 in a day or two unless there are any objections.
Looks good to me.
Were you able to test it against an extension containing both rules and
views, to check that pg_dump
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On 05/30/2013 02:02 AM, Dimitri Fontaine wrote:
Joe Conway m...@joeconway.com writes:
Here's a cleaned up version, which also includes documentation.
I'll commit back to 9.1 in a day or two unless there are any
objections.
Looks good to me.
Joe Conway m...@joeconway.com writes:
Were you able to test it against an extension containing both rules
and views, to check that pg_dump has no problem with the new set
of dependencies?
PostGIS has both:
[...]
# pg_dump test /tmp/test-02.dmp
# diff /tmp/test-01.dmp /tmp/test-02.dmp
Joe Conway m...@joeconway.com writes:
The attached one-liner seems to do the trick. It should probably be
backpatched to 9.1. Remaining questions:
Thanks for the patch (and testing, etc, that it entails)!
1) Are there other database object types, likely to be included in
extension
On 2013-05-29 09:30:43 +0200, Dimitri Fontaine wrote:
2) How should we handle already installed extensions, which will still
lack dependency records after this bugfix?
I don't really see any other way here than providing an upgrade script
that will somehow re-attach those objects,
Andres Freund and...@2ndquadrant.com writes:
On 2013-05-29 09:30:43 +0200, Dimitri Fontaine wrote:
2) How should we handle already installed extensions, which will still
lack dependency records after this bugfix?
I don't really see any other way here than providing an upgrade script
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On 05/29/2013 05:52 AM, Dimitri Fontaine wrote:
Andres Freund and...@2ndquadrant.com writes:
On 2013-05-29 09:30:43 +0200, Dimitri Fontaine wrote:
2) How should we handle already installed extensions, which
will still lack dependency records after
On 2013-05-29 07:35:42 -0700, Joe Conway wrote:
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On 05/29/2013 05:52 AM, Dimitri Fontaine wrote:
Andres Freund and...@2ndquadrant.com writes:
On 2013-05-29 09:30:43 +0200, Dimitri Fontaine wrote:
2) How should we handle already installed
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On 05/29/2013 07:43 AM, Andres Freund wrote:
On 2013-05-29 07:35:42 -0700, Joe Conway wrote:
On 05/29/2013 05:52 AM, Dimitri Fontaine wrote:
Andres Freund and...@2ndquadrant.com writes:
On 2013-05-29 09:30:43 +0200, Dimitri Fontaine wrote:
2) How
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On 05/29/2013 03:31 PM, Joe Conway wrote:
On 05/29/2013 07:43 AM, Andres Freund wrote:
Couldn't ALTER EXTENSION ... ADD ...; be brought up to
speed to support this?
Sounds better to me than manually fiddling with pg_depend... We
can't really
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On 04/06/2013 04:49 PM, Joe Conway wrote:
If I create a database and install postgis as an extension, and
then run pg_dump I get this:
[...] CREATE EXTENSION IF NOT EXISTS postgis WITH SCHEMA public;
[...] CREATE RULE geometry_columns_delete AS
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On 04/08/2013 08:34 AM, Dimitri Fontaine wrote:
Joe Conway m...@joeconway.com writes:
OK, maybe I'll try to take a look in the meantime.
That would be awesome :)
Did you have any comment on the other pg_dump patch (reviewed by
Vibhor)?
Joe Conway m...@joeconway.com writes:
Committed back to 9.1
Thanks,
--
Dimitri Fontaine
http://2ndQuadrant.fr PostgreSQL : Expertise, Formation et Support
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
Joe Conway m...@joeconway.com writes:
Shouldn't that CREATE RULE be implicitly part of the CREATE EXTENSION?
Yes. It's a bug, been reported before, it's on my todo list. I have
arranged some time to care about it while in beta, I won't be able to
have at it before then…
Regards,
--
Dimitri
On 04/08/2013 07:42 AM, Dimitri Fontaine wrote:
Joe Conway m...@joeconway.com writes:
Shouldn't that CREATE RULE be implicitly part of the CREATE EXTENSION?
Yes. It's a bug, been reported before, it's on my todo list. I have
arranged some time to care about it while in beta, I won't be able
Joe Conway m...@joeconway.com writes:
OK, maybe I'll try to take a look in the meantime.
That would be awesome :)
Did you have any comment on the other pg_dump patch (reviewed by Vibhor)?
This whole extension table filtering and dumping is more in Tom's realm,
so I guess that if you want to
If I create a database and install postgis as an extension, and then run
pg_dump I get this:
[...]
CREATE EXTENSION IF NOT EXISTS postgis WITH SCHEMA public;
[...]
CREATE RULE geometry_columns_delete AS ON DELETE TO geometry_columns DO
INSTEAD NOTHING;
[...]
Shouldn't that CREATE RULE be
33 matches
Mail list logo
