Re: pg_dump --where option

> On 14 Sep 2020, at 12:04, Surafel Temesgen <surafel3000(at)gmail(dot)com> wrote:
> On Fri, Jul 31, 2020 at 1:38 AM Daniel Gustafsson <daniel(at)yesql(dot)se <mailto:daniel(at)yesql(dot)se>> wrote:
>
> > $ 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.
> This is because pg_dump uses schema-qualified object name I add documentation about to use schema-qualified name when using sub query

Documenting something is well and good, but isn't allowing arbitrary SQL
copy-pasted into the query (which isn't checked for schema qualification)
opening up for some of the ill-effects of CVE-2018-1058?

> I don’t add tests because single-quotes and double-quotes are meta-characters for PROVE too.

I'm not sure I follow. Surely tests can be added for this functionality?

How should one invoke this on a multibyte char table name which require
quoting, like --table='"x"' (where x would be an mb char). Reading the
original thread and trying the syntax from there, it's also not clear how table
names with colons should be handled. I know they're not common, but if they're
not supported then the tradeoff should be documented.

A nearby thread [0] is adding functionality to read from an input file due to
the command line being too short. Consumers of this might not run into the
issues mentioned there, but it doesn't seem far fetched that someone who does
also adds a small WHERE clause too. Maybe these patches should join forces?

cheers ./daniel

[0] CAFj8pRB10wvW0CC9Xq=1XDs=zCQxer3cbLcNZa+qiX4cUH-G_A(at)mail(dot)gmail(dot)com