Re: [PATCH] Opclass parameters

From: Nikolay Shaplov <dhyan(at)nataraj(dot)su>
To: Nikita Glukhov <n(dot)gluhov(at)postgrespro(dot)ru>
Cc: PostgreSQL mailing lists <pgsql-hackers(at)postgresql(dot)org>, obartunov(at)gmail(dot)com
Subject: Re: [PATCH] Opclass parameters
Date: 2018-11-16 10:52:41
Message-ID: 8107388.VFAiSI6WnI@x200m
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

В письме от 15 ноября 2018 18:26:43 пользователь Nikita Glukhov написал:

> >> But since it is now "Rejected with feedback", let's wait till autumn.
> >
> > We don't want to wait that long. But now we only need to сome to an
> > agreement
> > about CREATE INDEX syntax and where to store the opclass parameters.
>
> Attached 2nd version of the patches. Nothing has changed since March,
> this is just a rebased version.
>
> CREATE INDEX syntax and parameters storage method still need discussion.

Hi! I'd like to review your patch if you do not mind. Since I am familiar
with the subject. I'll add it to the TOP 3 of my IT TODO list :-)

But even without carefully reading the code I have several important
questions:

1. I am sure that this patch should contain code for opclass praram generic
implementation, and _one_ example of how it is used for certain opclass.
From my point of view, we should not add all hardcoded constant as opclass
params just because we can. It should be done only when it is really needed.
And each case needs special consideration. This is not only about code
complexity, this worries me less, but also about documentation complexity.
Once option is added, it should be documented. This will make documentation
more hard to understand (and completely unexperienced users reads
documentation too). If this option is needed, this is price we all pay. But if
nobody really use it, I see no reason to make things more complex for
everyone.

2. The second question, is why you create new column in one of the table of
pg_catalog, when we have attopitions in attribute description. And each
indexed column in index is technically a relation attribute. Options of index
column should be stored there, from my point of view (yes I know it is a
hassle to pass it there, but I did in in my preview, it can be done)
2.1. I did not read the code, I'll do it some time late, but the main question
I have is, how you will manage case, when you set different values for same
options of different columns. like:

CREATE INDEX ON arrays USING gist (
arr1 gist__intbig_ops (siglen = 32),
arr2 gist__intbig_ops (siglen = 64)
);

It is easitly solved when you store them in attoptions. But my question how do
you manage it... (I'll get the answer from the code soon, I hope)

--
Do code for fun.

In response to

Browse pgsql-hackers by date

  From Date Subject
Next Message Jean-Christophe Arnu 2018-11-16 11:05:00 Re: wal_dump output on CREATE DATABASE
Previous Message Michael Paquier 2018-11-16 08:32:52 Re: ALTER INDEX ... ALTER COLUMN not present in dump