Re: [PROPOSAL] Covering + unique indexes.

From: Jim Nasby <Jim(dot)Nasby(at)BlueTreble(dot)com>
To: Anastasia Lubennikova <a(dot)lubennikova(at)postgrespro(dot)ru>, pgsql-hackers <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: [PROPOSAL] Covering + unique indexes.
Date: 2015-09-14 16:37:01
Message-ID: 55F6F7AD.4080307@BlueTreble.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

On 9/11/15 7:45 AM, Anastasia Lubennikova wrote:
> This idea has obvious restriction. We can set unique only for first
> index columns.
> There is no clear way to maintain following index.
> CREATE INDEX index ON table (c1, c2, c3) UNIQUE ON (c1, c3);
>
> So I suggest following syntax:
> CREATE [UNIQUE {ON FIRST {COLUMN | n_unique_column COLUMNS}} INDEX ON
> table_name (column_name1, column_name2 ...);

I would use the first (simple) syntax and just throw an error if the
user tries to skip a column on the UNIQUE clause.

Have you by chance looked to see what other databases have done for
syntax? I'm guessing this isn't covered by ANSI but maybe there's
already an industry consensus.
--
Jim Nasby, Data Architect, Blue Treble Consulting, Austin TX
Experts in Analytics, Data Architecture and PostgreSQL
Data in Trouble? Get it in Treble! http://BlueTreble.com

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Jim Nasby 2015-09-14 16:43:45 Re: Do Layered Views/Relations Preserve Sort Order ?
Previous Message Stephen Frost 2015-09-14 16:16:56 Re: RLS open items are vague and unactionable