Re: pg_dump --where option - Mailing list pgsql-hackers

From Daniel Gustafsson
Subject Re: pg_dump --where option
Date
Msg-id 0066D8E5-CB81-4644-84E8-C39B50B15AB0@yesql.se
Whole thread Raw
In response to Re: pg_dump --where option  (Cary Huang <cary.huang@highgo.ca>)
Responses Re: pg_dump --where option
List pgsql-hackers
> On 10 Jul 2020, at 02:03, Cary Huang <cary.huang@highgo.ca> wrote:
>
> The following review has been posted through the commitfest application:
> make installcheck-world:  tested, failed
> Implements feature:       tested, failed
> Spec compliant:           tested, failed
> Documentation:            tested, failed
>
> Hi
>
> I had a look at the patch and it cleanly applies to postgres master branch. I tried to do a quick test on the new
"whereclause" functionality and for the most part it does the job as described and I'm sure some people will find this
featureuseful to their database dump needs. However I tried the feature with a case where I have a subquery in the
whereclause, but it seems to be failing to dump the data. I ran the pg_dump like: 
>
>  $ pg_dump -d cary --where="test1:a3 = ( select max(aa1) from test2 )" > testdump2
>  $ pg_dump: error: processing of table "public.test1" failed
>
> both test1 and test2 exist in the database and the same subquery works under psql.
>
> I also notice that the regression tests for pg_dump is failing due to the patch, I think it is worth looking into the
failuremessages and also add some test cases on the new "where" clause to ensure that it can cover as many use cases as
possible.

As this is being reviewed, but time is running out in this CF, I'm moving this
to the next CF.  The entry will be moved to Waiting for Author based on the
above review.

cheers ./daniel


pgsql-hackers by date:

Previous
From: Daniel Gustafsson
Date:
Subject: Re: ModifyTable overheads in generic plans
Next
From: Peter Geoghegan
Date:
Subject: logtape.c stats don't account for unused "prefetched" block numbers