On Tue, Sep 29, 2015 at 9:39 PM, Michael Paquier wrote:
> Perhaps you did not look at the last patch I sent on this thread, but
> I changed it so as a schedule is used with a call to pg_regress.
> That's a more scalable approach as you were concerned about as we can
> plug in more easily new module
On Sat, Sep 26, 2015 at 10:22 PM, Andres Freund wrote:
> On 2015-09-26 21:54:46 +0900, Michael Paquier wrote:
>> On Wed, Sep 23, 2015 at 1:04 AM, Alvaro Herrera
>> wrote:
>> > We discussed this in some other thread, not long ago. I looked briefly
>> > in the archives but couldn't find it. I thi
On 2015-09-26 21:54:46 +0900, Michael Paquier wrote:
> On Wed, Sep 23, 2015 at 1:04 AM, Alvaro Herrera
> wrote:
> > We discussed this in some other thread, not long ago. I looked briefly
> > in the archives but couldn't find it. I think the conclusion was
> > something along the lines of "hmm, t
On Wed, Sep 23, 2015 at 1:04 AM, Alvaro Herrera
wrote:
> Euler Taveira wrote:
> > On 17-09-2015 14:21, Michael Paquier wrote:
> > >pg_dump relies on attnum to define the column ordering, so one
> > >possibility would be to do things more consistently at backend level.
>
> We discussed this in som
Euler Taveira wrote:
> On 17-09-2015 14:21, Michael Paquier wrote:
> >pg_dump relies on attnum to define the column ordering, so one
> >possibility would be to do things more consistently at backend level.
We discussed this in some other thread, not long ago. I looked briefly
in the archives but
On 17-09-2015 14:21, Michael Paquier wrote:
pg_dump relies on attnum to define the column ordering, so one
possibility would be to do things more consistently at backend level.
Thoughts?
According to your example, problem is the columns from the parent table
"aa" are added _before_ declaring th
On Thu, Sep 17, 2015 at 9:47 AM, Michael Paquier wrote:
> COPY or INSERT include the column list in dumps, so that's not really
> an issue here, what is potentially a problem (looking at that freshly)
> is --inserts with data-only dumps though. So yes we had better fix it
> and perhaps consider a b
On Thu, Sep 17, 2015 at 7:24 AM, Andres Freund wrote:
> On 2015-09-16 22:18:55 -0700, Michael Paquier wrote:
>> Problem is similar with --column-inserts, --inserts and COPY. We could
>> use --exclude-table like in the patch attached when taking the dump
>> from source database but that's grotty, or
On 2015-09-16 22:18:55 -0700, Michael Paquier wrote:
> So, here we go.
Cool.
> I have found something quite interesting when playing with the patch
> attached: dump does not guarantee the column ordering across databases
> for some inherited tables, see that example from the main regression
> tes
On Wed, Sep 16, 2015 at 8:00 PM, Michael Paquier wrote:
> Hm. OK. I didn't get your message correctly, sorry for that. Would you
> be fine then to have a pg_regress command using parallel_schedule + an
> extra schedule launching tests related to the extensions in
> src/test/modules/pg_dumprestore t
On Wed, Sep 16, 2015 at 3:42 PM, Andres Freund wrote:
> On 2015-09-09 10:48:24 +0900, Michael Paquier wrote:
>> On Wed, Sep 9, 2015 at 3:33 AM, Andres Freund wrote:
>> > On 2015-09-07 22:55:50 +0900, Michael Paquier wrote:
>> >> So, to summarize the state of this patch whose status is now "Waitin
On 2015-09-09 10:48:24 +0900, Michael Paquier wrote:
> On Wed, Sep 9, 2015 at 3:33 AM, Andres Freund wrote:
> > On 2015-09-07 22:55:50 +0900, Michael Paquier wrote:
> >> So, to summarize the state of this patch whose status is now "Waiting
> >> on Author", we have the following possibilities:
> >>
On Wed, Sep 9, 2015 at 3:33 AM, Andres Freund wrote:
> On 2015-09-07 22:55:50 +0900, Michael Paquier wrote:
>> So, to summarize the state of this patch whose status is now "Waiting
>> on Author", we have the following possibilities:
>> 1) Keep the test as-is, as an independent test of src/test/mod
On Wed, Sep 2, 2015 at 02:30:33PM -0300, Alvaro Herrera wrote:
> > I think we should rather add *one* test that does dump/restore over the
> > normal regression test database. Something similar to the pg_upgrade
> > tests. And then work at adding more content to the regression test
> > database -
On 2015-09-07 22:55:50 +0900, Michael Paquier wrote:
> So, to summarize the state of this patch whose status is now "Waiting
> on Author", we have the following possibilities:
> 1) Keep the test as-is, as an independent test of src/test/modules.
I find that a bad option. A test that takes this lon
On Thu, Sep 3, 2015 at 10:35 AM, Michael Paquier
wrote:
> On Thu, Sep 3, 2015 at 12:38 AM, Andres Freund wrote:
>> Isn't a full test with a separate initdb, create extension etc. a really
>> heavyhanded way to test this? I mean that's a test where the setup takes
>> up to 10s, whereas the actual r
On Thu, Sep 3, 2015 at 12:38 AM, Andres Freund wrote:
> Isn't a full test with a separate initdb, create extension etc. a really
> heavyhanded way to test this? I mean that's a test where the setup takes
> up to 10s, whereas the actual runtime is in the millisecond range?
>
> Adding tests in this m
On Thu, Sep 3, 2015 at 2:30 AM, Alvaro Herrera wrote:
> Andres Freund wrote:
>> Isn't a full test with a separate initdb, create extension etc. a really
>> heavyhanded way to test this? I mean that's a test where the setup takes
>> up to 10s, whereas the actual runtime is in the millisecond range?
Andres Freund wrote:
> > As I recall, Andrew Dunstan has a module that
> > tests cross-version pg_upgrade and one thing he does is dump both and
> > compare; the problem is that there are differences, so he keeps a count
> > of how many lines he expect to differ between any two releases.
>
> I'm
On 2015-09-02 14:30:33 -0300, Alvaro Herrera wrote:
> I was thinking in having this be renamed src/test/modules/extensions/
> and then the extension contained here would be renamed ext001_fk_tables
> or something like that; later we could ext002_something for testing some
> other angle of extension
Andres Freund wrote:
> Isn't a full test with a separate initdb, create extension etc. a really
> heavyhanded way to test this? I mean that's a test where the setup takes
> up to 10s, whereas the actual runtime is in the millisecond range?
I spent some time looking over this patch yesterday, and
On 2015-08-02 19:15:58 -0700, Michael Paquier wrote:
> +psql 'postgres', 'CREATE EXTENSION tables_fk';
> +
> +# Insert some data before running the dump, this is needed to check
> +# consistent data dump of tables with foreign key dependencies
> +psql 'postgres', 'INSERT INTO cc_tab_fkey VALUES (1)
On Thu, Jul 30, 2015 at 5:35 PM, Michael Paquier
wrote:
> Note as well that I will be fine with any decision taken by the
> committer who picks up this, this test case is useful by itself in any
> case.
And I just recalled that I actually did no tests for this thing on
Windows. As this uses the T
On Fri, Jul 31, 2015 at 6:41 AM, Andreas Karlsson wrote:
> The comment is good, but what I personally do not like is that the path to
> the test suite is non-obvious and not self explanatory I would not expect
> src/test/tables_fk/t/ to test pg_dump and extensions. I find it to confusing
> to rega
On 07/30/2015 04:48 AM, Michael Paquier wrote:
On Thu, Jul 30, 2015 at 5:54 AM, Andreas Karlsson wrote:
What I do not like though is how the path src/test/tables_fk/t/ tells us
nothing about what features are of PostgreSQL are tested here. For this I
personally prefer the earlier versions where
On Thu, Jul 30, 2015 at 5:54 AM, Andreas Karlsson wrote:
> What I do not like though is how the path src/test/tables_fk/t/ tells us
> nothing about what features are of PostgreSQL are tested here. For this I
> personally prefer the earlier versions where I think that was clear.
+Simple module use
I have reviewed this patch and it compiles runs and the new test case
passes. The code is also clean and the test seems like a useful
regression test.
What I do not like though is how the path src/test/tables_fk/t/ tells us
nothing about what features are of PostgreSQL are tested here. For thi
On Wed, Jul 8, 2015 at 1:32 AM, Heikki Linnakangas wrote:
> Hmm. I think it'd be better to put the tables_fk extension into
> src/test/modules, and the test case under src/test/tables_fk/t/. I'm
> inclined to think of this as a test case for an extension that contains a
> table, which includes tes
On 03/07/2015 02:34 PM, Michael Paquier wrote:
On Tue, Mar 3, 2015 at 2:40 PM, Michael Paquier
wrote:
Those patches are really simple, but then perhaps there are better or
simpler ways than what is attached, so feel free to comment if you
have any ideas.
Attached are new patches somewhat base
On Tue, Mar 3, 2015 at 2:40 PM, Michael Paquier
wrote:
> Those patches are really simple, but then perhaps there are better or
> simpler ways than what is attached, so feel free to comment if you
> have any ideas.
Attached are new patches somewhat based on the comments provided by
Peter Eisentrau
Hi all,
While investigating the issue that has been committed as ebd092b to
fix FK dependencies in pg_dump for tables in extensions, I developed a
small test case aimed for integration in src/test/modules to ensure
that this does not break again in the future. Note that as the
regression tests of
31 matches
Mail list logo
