Re: pg_dump --where option

From: Cary Huang <cary(dot)huang(at)highgo(dot)ca>
To: pgsql-hackers(at)lists(dot)postgresql(dot)org
Cc: Surafel Temesgen <surafel3000(at)gmail(dot)com>, Carter Thaxton <carter(dot)thaxton(at)gmail(dot)com>
Subject: Re: pg_dump --where option
Date: 2020-07-10 00:03:57
Message-ID: 159433943749.1150.5754029070727088340.pgcf@coridan.postgresql.org
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

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.

thank you
Best regards

Cary Huang
-------------
HighGo Software Inc. (Canada)
cary(dot)huang(at)highgo(dot)ca
www.highgo.ca

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Alvaro Herrera 2020-07-10 00:08:38 Re: Stale external URL in doc?
Previous Message David G. Johnston 2020-07-09 23:57:22 Re: Default setting for enable_hashagg_disk