Re: cannot restore schema with is not distinct from on hstore since PG 9.6.8

On 07/09/2018 11:34 AM, Tom Lane wrote:
> Marc Cousin <cousinmarc(at)gmail(dot)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