Re: [HACKERS] Improving test coverage of extensions with pg_dump

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

Re: [HACKERS] Improving test coverage of extensions with pg_dump

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 >>

Re: [HACKERS] Improving test coverage of extensions with pg_dump

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. >

Re: [HACKERS] Improving test coverage of extensions with pg_dump

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

Re: [HACKERS] Improving test coverage of extensions with pg_dump

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

Re: [HACKERS] Improving test coverage of extensions with pg_dump

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

Re: [HACKERS] Improving test coverage of extensions with pg_dump

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,

Re: [HACKERS] Improving test coverage of extensions with pg_dump

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 >

Re: [HACKERS] Improving test coverage of extensions with pg_dump

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

Re: [HACKERS] Improving test coverage of extensions with pg_dump

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

Re: [HACKERS] Improving test coverage of extensions with pg_dump

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

Re: [HACKERS] Improving test coverage of extensions with pg_dump

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

Re: [HACKERS] Improving test coverage of extensions with pg_dump

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

Re: [HACKERS] Improving test coverage of extensions with pg_dump

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 -

Re: [HACKERS] Improving test coverage of extensions with pg_dump

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

Re: [HACKERS] Improving test coverage of extensions with pg_dump

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

Re: [HACKERS] Improving test coverage of extensions with pg_dump

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

Re: [HACKERS] Improving test coverage of extensions with pg_dump

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

Re: [HACKERS] Improving test coverage of extensions with pg_dump

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

Re: [HACKERS] Improving test coverage of extensions with pg_dump

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

Re: [HACKERS] Improving test coverage of extensions with pg_dump

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?

Re: [HACKERS] Improving test coverage of extensions with pg_dump

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

Re: [HACKERS] Improving test coverage of extensions with pg_dump

On Thu, Jul 30, 2015 at 5:35 PM, Michael Paquier michael.paqu...@gmail.com 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

Re: [HACKERS] Improving test coverage of extensions with pg_dump

On Fri, Jul 31, 2015 at 6:41 AM, Andreas Karlsson andr...@proxel.se 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

Re: [HACKERS] Improving test coverage of extensions with pg_dump

On 07/30/2015 04:48 AM, Michael Paquier wrote: On Thu, Jul 30, 2015 at 5:54 AM, Andreas Karlsson andr...@proxel.se 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

Re: [HACKERS] Improving test coverage of extensions with pg_dump

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

Re: [HACKERS] Improving test coverage of extensions with pg_dump

On Thu, Jul 30, 2015 at 5:54 AM, Andreas Karlsson andr...@proxel.se 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.

Re: [HACKERS] Improving test coverage of extensions with pg_dump

On Wed, Jul 8, 2015 at 1:32 AM, Heikki Linnakangas hlinn...@iki.fi 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

Re: [HACKERS] Improving test coverage of extensions with pg_dump

On Tue, Mar 3, 2015 at 2:40 PM, Michael Paquier michael.paqu...@gmail.com 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