Re: [PATCH] Opclass parameters
Robert Haas <robertmhaas@gmail.com>
From: Robert Haas <robertmhaas@gmail.com>
To: Nikolay Shaplov <dhyan@nataraj.su>
Cc: PostgreSQL Hackers <pgsql-hackers@lists.postgresql.org>, Nikita Glukhov <n.gluhov@postgrespro.ru>, "pgsql-hackers@postgresql.org" <pgsql-hackers@postgresql.org>,
Oleg Bartunov <obartunov@gmail.com>
Date: 2018-11-21T15:04:17Z
Lists: pgsql-hackers
On Wed, Feb 28, 2018 at 9:46 AM Nikolay Shaplov <dhyan@nataraj.su> wrote: > 1. I've seen you've added a new attribute into pg_index. Why??!! > As far as I can get, if have index built on several columns (A1, A2, A3) you > can set, own opclass for each column. And set individual options for each > opclass if we are speaking about options. So I would expect to have these > options not in pg_index, but in pg_attribute. And we already have one there: > attoptions.I just do not get how you have come to per-index options. May be I > should read code more attentively... It seems sensible to have both per-column options and per-index options. For example, we've got the fastupdate option for GIN, which is a property of the index as a whole, not any individual column. But you could also want to specify some column-specific options, which seems to be what this patch is about, since an opclass is associated with an individual column. And since an index can have more than one column, I agree that it seems more appropriate to store this information in pg_attribute than pg_index. -- Robert Haas EnterpriseDB: http://www.enterprisedb.com The Enterprise PostgreSQL Company
Commits
-
Documentation corrections for opclass parameters
- 3f1802e1fdb7 13.0 landed
-
Implement operator class parameters
- 911e70207703 13.0 landed