Joe Conway 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:
http://www.postgresql.org/mailpr
-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;
Joe Conway 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
> go one level de
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On 06/02/2013 03:10 PM, Dimitri Fontaine wrote:
> Tom Lane 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 :-)
New patch atta
Tom Lane 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 dependency tracking
-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 a
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 eve
Joe Conway 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 rewrite rules\n");
-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
On 2013-06-01 11:31:05 -0400, Tom Lane wrote:
> Andres Freund 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
Andres Freund 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 adds the
> miss
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On 06/01/2013 08:07 AM, Tom Lane wrote:
> Joe Conway 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 t
On 2013-06-01 11:07:53 -0400, Tom Lane wrote:
> Joe Conway 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
Joe Conway 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
> existing
-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
> 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 com
On Wed, May 29, 2013 at 6:55 PM, Joe Conway 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 up version
Joe Conway 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
> ..
Per
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On 05/30/2013 02:02 AM, Dimitri Fontaine wrote:
> Joe Conway 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
Joe Conway 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 has no problem wi
-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
>> c
-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 writes:
On 2013-05-29 09:30:43 +0200, Dimitri Fontaine wrote:
>> 2) How should
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 writes:
> >> On 2013-05-29 09:30:43 +0200, Dimitri Fontaine wrote:
> 2) How should we handle already installed extensions, w
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On 05/29/2013 05:52 AM, Dimitri Fontaine wrote:
> Andres Freund 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
Andres Freund 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
>> that will so
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,
Joe Conway 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 scripts, that are also
-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_delet
Joe Conway 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:
http://www.postgresql.org/mailpref/pgsql-ha
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On 04/08/2013 08:34 AM, Dimitri Fontaine wrote:
> Joe Conway 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
Joe Conway 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 have another pair
On 04/08/2013 07:42 AM, Dimitri Fontaine wrote:
> Joe Conway 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
Joe Conway 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 Fontaine
http://2ndQu
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 implicit
33 matches
Mail list logo
