Re: pg_dump --where option

From: Daniel Gustafsson <daniel(at)yesql(dot)se>
To: Surafel Temesgen <surafel3000(at)gmail(dot)com>
Cc: Postgres hackers <pgsql-hackers(at)lists(dot)postgresql(dot)org>, Carter Thaxton <carter(dot)thaxton(at)gmail(dot)com>, Cary Huang <cary(dot)huang(at)highgo(dot)ca>
Subject: Re: pg_dump --where option
Date: 2020-07-30 22:38:10
Message-ID: 0066D8E5-CB81-4644-84E8-C39B50B15AB0@yesql.se
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

> On 10 Jul 2020, at 02:03, Cary Huang <cary(dot)huang(at)highgo(dot)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 "where clause" functionality and for the most part it does the job as described and I'm sure some people will find this feature useful to their database dump needs. However I tried the feature with a case where I have a subquery in the where clause, 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 failure messages 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

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Peter Geoghegan 2020-07-30 22:51:00 logtape.c stats don't account for unused "prefetched" block numbers
Previous Message Daniel Gustafsson 2020-07-30 22:30:43 Re: ModifyTable overheads in generic plans