Michael Paquier writes:
> On Tue, Aug 30, 2016 at 5:43 AM, MartÃn Marqués
> wrote:
>> This is v4 of the patch, which is actually a cleaner version from the
>> v2 one Michael sent.
> Let's do as you suggest then, and just focus on the schema issue. I
> just had an extra look at the patch and i
2016-08-30 2:02 GMT-03:00 Michael Paquier :
> On Tue, Aug 30, 2016 at 5:43 AM, Martín Marqués
> wrote:
>> This is v4 of the patch, which is actually a cleaner version from the
>> v2 one Michael sent.
>>
>> I stripped off the external index created from the tests as that index
>> shouldn't be dump
On Tue, Aug 30, 2016 at 5:43 AM, Martín Marqués wrote:
> This is v4 of the patch, which is actually a cleaner version from the
> v2 one Michael sent.
>
> I stripped off the external index created from the tests as that index
> shouldn't be dumped (table it belongs to isn't dumped, so neither
> sho
Hi,
This is v4 of the patch, which is actually a cleaner version from the
v2 one Michael sent.
I stripped off the external index created from the tests as that index
shouldn't be dumped (table it belongs to isn't dumped, so neither
should the index). I also took off a test which was duplicated.
2016-08-29 4:51 GMT-03:00 Michael Paquier :
>
>> I see the current behavior is documented, and I do understand why global
>> objects can't be part of the extension, but for indexes it seems to violate
>> POLA a bit.
>>
>> Is there a reason why we don't want the extension/index dependencies?
>
> I t
On Sat, Aug 27, 2016 at 8:15 AM, Tomas Vondra
wrote:
> On 08/27/2016 12:37 AM, Tom Lane wrote:
>> =?UTF-8?B?TWFydMOtbiBNYXJxdcOpcw==?= writes:
>>> Looking at this issue today, I found that we are not setting a
>>> dependency for an index created inside an extension.
>>
>> Surely the index has a d
2016-08-26 19:37 GMT-03:00 Tom Lane :
> =?UTF-8?B?TWFydMOtbiBNYXJxdcOpcw==?= writes:
>> Looking at this issue today, I found that we are not setting a
>> dependency for an index created inside an extension.
>
> Surely the index has a dependency on a table, which depends on the
> extension?
>
> If
On 08/26/2016 04:15 PM, Tomas Vondra wrote:
On 08/27/2016 12:37 AM, Tom Lane wrote:
=?UTF-8?B?TWFydMOtbiBNYXJxdcOpcw==?= writes:
Looking at this issue today, I found that we are not setting a
dependency for an index created inside an extension.
Surely the index has a dependency on a table, w
Tomas Vondra writes:
> On 08/27/2016 12:37 AM, Tom Lane wrote:
>> If you mean that you want an extension to create an index on a table
>> that doesn't belong to it, but it's assuming pre-exists, I think
>> that's just stupid and we need not support it.
> I don't see why that would be stupid (and
On 08/27/2016 12:37 AM, Tom Lane wrote:
=?UTF-8?B?TWFydMOtbiBNYXJxdcOpcw==?= writes:
Looking at this issue today, I found that we are not setting a
dependency for an index created inside an extension.
Surely the index has a dependency on a table, which depends on the
extension?
If you mean t
=?UTF-8?B?TWFydMOtbiBNYXJxdcOpcw==?= writes:
> Looking at this issue today, I found that we are not setting a
> dependency for an index created inside an extension.
Surely the index has a dependency on a table, which depends on the
extension?
If you mean that you want an extension to create an i
Hi,
2016-08-26 10:53 GMT-03:00 Martín Marqués :
>
> There's still one issue, which I'll add a test for as well, which is
> that if the index was created by the extension, it will be dumped
> anyway. I'll have a look at that as well.
Looking at this issue today, I found that we are not setting a
d
Hi,
2016-08-25 8:10 GMT-03:00 Michael Paquier :
> On Thu, Aug 25, 2016 at 10:25 AM, Martín Marqués
> wrote:
>> 2016-08-24 21:34 GMT-03:00 Michael Paquier :
>>>
>>> Yes, you are right. If I look at the diffs this morning I am seeing
>>> the ACLs being dumped for this aggregate. So we could just f
On Thu, Aug 25, 2016 at 10:25 AM, Martín Marqués wrote:
> 2016-08-24 21:34 GMT-03:00 Michael Paquier :
>>
>> Yes, you are right. If I look at the diffs this morning I am seeing
>> the ACLs being dumped for this aggregate. So we could just fix the
>> test and be done with it. I did not imagine the
2016-08-24 21:34 GMT-03:00 Michael Paquier :
>
> Yes, you are right. If I look at the diffs this morning I am seeing
> the ACLs being dumped for this aggregate. So we could just fix the
> test and be done with it. I did not imagine the index issue though,
> and this is broken for some time, so that
On Wed, Aug 24, 2016 at 11:15 PM, Stephen Frost wrote:
> * Michael Paquier (michael.paqu...@gmail.com) wrote:
>> The patch attached includes all those tests and they are failing. We
>> are going to need a patch able to pass all that, and even for master
>> this is going to need more thoughts, and
2016-08-24 17:01 GMT-03:00 Martín Marqués :
> 2016-08-24 11:15 GMT-03:00 Stephen Frost :
>> Michael,
>>
>> * Michael Paquier (michael.paqu...@gmail.com) wrote:
>>> The patch attached includes all those tests and they are failing. We
>>> are going to need a patch able to pass all that, and even for
2016-08-24 11:15 GMT-03:00 Stephen Frost :
> Michael,
>
> * Michael Paquier (michael.paqu...@gmail.com) wrote:
>> The patch attached includes all those tests and they are failing. We
>> are going to need a patch able to pass all that, and even for master
>> this is going to need more thoughts, and
Michael,
* Michael Paquier (michael.paqu...@gmail.com) wrote:
> The patch attached includes all those tests and they are failing. We
> are going to need a patch able to pass all that, and even for master
> this is going to need more thoughts, and let's focus on HEAD/9.6
> first.
Are you sure you
On Wed, Aug 24, 2016 at 9:07 AM, Michael Paquier
wrote:
> On Wed, Aug 24, 2016 at 5:34 AM, Martín Marqués
> wrote:
>> Hi,
>>
>> 2016-08-23 16:46 GMT-03:00 Martín Marqués :
>>>
>>> I will add tests for sequence and functions as you mention and test again.
>>>
>>> Then I'll check if other tests sh
On Wed, Aug 24, 2016 at 5:34 AM, Martín Marqués wrote:
> Hi,
>
> 2016-08-23 16:46 GMT-03:00 Martín Marqués :
>>
>> I will add tests for sequence and functions as you mention and test again.
>>
>> Then I'll check if other tests should be added as well.
>
> I found quite some other objects we should
On 8/23/16 3:34 PM, Martín Marqués wrote:
I found quite some other objects we should be checking as well, but
this will add some duplication to the tests, as I'd just copy (with
minor changes) what's in src/bin/pg_dump/t/002_pg_dump.pl
I can't think of a way to avoid this duplication, not that i
Hi,
2016-08-23 16:46 GMT-03:00 Martín Marqués :
>
> I will add tests for sequence and functions as you mention and test again.
>
> Then I'll check if other tests should be added as well.
I found quite some other objects we should be checking as well, but
this will add some duplication to the test
Hi Michael,
2016-08-23 5:02 GMT-03:00 Michael Paquier :
> On Sat, Aug 13, 2016 at 6:58 AM, Martín Marqués
> wrote:
>> I believe the fix will be simple after the back and forth mails with
>> Michael, Stephen and Tom. I will work on that later, but preferred to
>> have the tests the show the probl
On Sat, Aug 13, 2016 at 6:58 AM, Martín Marqués wrote:
> I believe the fix will be simple after the back and forth mails with
> Michael, Stephen and Tom. I will work on that later, but preferred to
> have the tests the show the problem which will also make testing the fix
> easier.
>
> Thoughts?
Hi,
About a month or two ago I reported a pg_dump bug regarding tables (and
other objects) created inside a schema from an extension.
Objects created by the extensions are not dumped, as they will be
created once again with the CREATE EXTENSION call, but and other objects
which might live inside
26 matches
Mail list logo
