On Tue, Jan 12, 2016 at 8:59 AM, Anastasia Lubennikova
<a.lubennikova@postgrespro.ru> wrote:
> 08.01.2016 00:12, David Rowley:
>
> On 7 January 2016 at 06:36, Jeff Janes <jeff.janes@gmail.com> wrote:
>>
> But now I see the reason to create non-unique index with included columns -
> lack of suitable opclass on column "b".
> It's impossible to add it into the index as a key column, but that's not a
> problem with INCLUDING clause.
> Look at example.
>
> create table t1 (a int, b box);
> create index t1_a_inc_b_idx on t1 (a) including (b);
> create index on tbl (a,b);
> ERROR: data type box has no default operator class for access method
> "btree"
> HINT: You must specify an operator class for the index or define a default
> operator class for the data type.
> create index on tbl (a) including (b);
> CREATE INDEX
>
> This functionality is provided by the attached patch "omit_opclass_4.0",
> which must be applied over covering_unique_4.0.patch.
Thanks for the updates.
Why is omit_opclass a separate patch? If the included columns now
never participate in the index ordering, shouldn't it be an inherent
property of the main patch that you can "cover" things without btree
opclasses?
Are you keeping them separate just to make review easier? Or do you
think there might be a reason to commit one but not the other? I
think that if we decide not to use the omit_opclass patch, then we
should also not allow covering columns to be specified on non-unique
indexes.
It looks like the "covering" patch, with or without the "omit_opclass"
patch, does not support expressions as included columns:
create table foobar (x text, y xml);
create index on foobar (x) including (md5(x));
ERROR: unrecognized node type: 904
create index on foobar (x) including ((y::text));
ERROR: unrecognized node type: 911
I think we would probably want it to work with those (or at least to
throw a better error message).
Thanks,
Jeff
