[ just to tie back to this old thread ]
I wrote:
> I poked into this area for awhile, and it turns out to be even a
> worse can of worms than I thought. I looked through gram.y and
> parse_expr.c, and identified several distinct classes of issue.
> (I'm not promising that I found everything.)
On 07/13/2018 05:23 PM, Tom Lane wrote:
"David G. Johnston" writes:
I think serious consideration needs to be given to ways to allow the user
of pg_dump/pg_restore to choose the prior, less secure, mode of operation​.
IMO the risk surface presented to support back-patching the behavioral
"David G. Johnston" writes:
> I think serious consideration needs to be given to ways to allow the user
> of pg_dump/pg_restore to choose the prior, less secure, mode of operation​.
> IMO the risk surface presented to support back-patching the behavioral
> changes was not severe enough to do so
On Fri, Jul 13, 2018 at 1:54 PM, Tom Lane wrote:
> So this is all pretty messy, but on the bright side, fixing it would allow
> cleaning up some ancient squishy coding in ruleutils.c. It wouldn't be
> controversial as just a v12 addition, perhaps ... but do we have a choice
> about
Andrew Dunstan writes:
> On 07/09/2018 11:34 AM, Tom Lane wrote:
>> 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
On 07/09/2018 11:34 AM, Tom Lane wrote:
Marc Cousin 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
Marc Cousin 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
>
