On 07/09/2018 11:34 AM, Tom Lane wrote:
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.
I agree with your approach, including backpatching. I guess we'll have to try to think of
some scenario that backpatching would break. Maybe to minimize any effect it should fall
back on a default opclass if the search for "=" fails? Dunno how practical that
is.
cheers
andrew
--
Andrew Dunstan https://www.2ndQuadrant.com
PostgreSQL Development, 24x7 Support, Remote DBA, Training & Services
