Marc Cousin <cousinm...@gmail.com> writes:
> This is a really simple test case, I think it's an unintended
> consequence of CVE-2018-1058:
> demo=# create extension hstore;
> CREATE EXTENSION
> demo=# create table test (a hstore);
> CREATE TABLE
> demo=# create index idx_test_not_distinct on test(a) where a is not
> distinct from '';
> CREATE INDEX
> [ whereupon dump/restore fails with ]
> CREATE INDEX idx_test_not_distinct ON public.test USING btree (a) WHERE
> (NOT (a IS DISTINCT FROM ''::public.hstore));
> psql:/tmp/demo_bug:73: ERROR: operator does not exist: public.hstore =
> public.hstore
Yeah, the core of the problem here is that there's no way to
schema-qualify IS [NOT] DISTINCT FROM's choice of underlying operator.
It was possible to ignore that as long as the operator you wanted
was in the search path, but now that we've tightened up pg_dump's
search path settings, we can't play fast and loose anymore.
I think the most practical way to deal with this probably is to change
the parser so that the lookup works by finding a default btree or hash
opclass rather than by looking for "=" by name. We've made similar
changes in the past to get rid of implicit dependencies on operator
names, but those efforts never reached IS [NOT] DISTINCT FROM.
I have a nasty feeling that there are still operator name dependencies
elsewhere, notably in CASE expressions, but haven't researched it yet.
Although this doesn't seem like an outlandish change to make in HEAD,
back-patching it might cause some issues. On the other hand, I don't
see what choice we have. Leaving things as they stand isn't very
workable, and inventing some kind of schema-qualification syntax for
IS [NOT] DISTINCT FROM is surely even worse from a backwards
compatibility standpoint.
Thoughts?
regards, tom lane
