From: Nikolay Shaplov <dhyan@nataraj.su>
To: Nikita Glukhov <n.gluhov@postgrespro.ru>
Cc: PostgreSQL mailing lists <pgsql-hackers@postgresql.org>,
 obartunov@gmail.com
Subject: Re: [PATCH] Opclass parameters
Date: Fri, 16 Nov 2018 13:52:41 +0300
Message-ID: <8107388.VFAiSI6WnI@x200m>
User-Agent: KMail/4.14.1 (Linux/3.16.0-4-amd64; KDE/4.14.2; x86_64; ; )
In-Reply-To: <71c6164e-59ad-e0c4-76c5-b1dfdd68eee3@postgrespro.ru>
References: <d22c3a18-31c7-1879-fc11-4c1ce2f5e5af@postgrespro.ru>
 <6382cb29-83d8-90f2-1dbb-b4ac606cbf1f@postgrespro.ru>
 <71c6164e-59ad-e0c4-76c5-b1dfdd68eee3@postgrespro.ru>
MIME-Version: 1.0
Content-Type: multipart/signed; boundary="nextPart1749732.Q2npTO9Sal";
 micalg="pgp-sha256"; protocol="application/pgp-signature"
Precedence: bulk


--nextPart1749732.Q2npTO9Sal
Content-Transfer-Encoding: quoted-printable
Content-Type: text/plain; charset="utf-8"

=D0=92 =D0=BF=D0=B8=D1=81=D1=8C=D0=BC=D0=B5 =D0=BE=D1=82 15 =D0=BD=D0=BE=
=D1=8F=D0=B1=D1=80=D1=8F 2018 18:26:43 =D0=BF=D0=BE=D0=BB=D1=8C=D0=B7=D0=
=BE=D0=B2=D0=B0=D1=82=D0=B5=D0=BB=D1=8C Nikita Glukhov =D0=BD=D0=B0=D0=BF=
=D0=B8=D1=81=D0=B0=D0=BB:

> >> But since it is now "Rejected with feedback", let's wait till autu=
mn.
> >=20
> > We don't want to wait that long.  But now we only need to =D1=81ome=
 to an
> > agreement
> > about CREATE INDEX syntax and where to store the opclass parameters=
.
>=20
> Attached 2nd version of the patches. Nothing has changed since March,=

> this is just a rebased version.
>=20
> CREATE INDEX syntax and parameters storage method still need discussi=
on.

Hi! I'd like to review your patch if you do  not mind. Since I am famil=
iar=20
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=20=

questions:

1. I am sure that this patch should contain code for opclass praram gen=
eric=20
implementation, and _one_ example of how it is used for certain opclass=
.
From=20my point of view, we should not add all hardcoded constant as opcl=
ass=20
params just because we can. It should be done only when it is really ne=
eded.=20
And each case needs special consideration. This is not only about code=20=

complexity, this worries me less, but also about documentation complexi=
ty.=20
Once option is added, it should be documented. This will make documenta=
tion=20
more hard to understand (and completely unexperienced users reads=20
documentation too). If this option is needed, this is price we all pay.=
 But if=20
nobody really use it, I see no reason to make things more complex for=20=

everyone.

2. The second question, is why you create new column in one of the tabl=
e of=20
pg_catalog, when we have attopitions in attribute description. And each=
=20
indexed column in index is technically a relation attribute. Options of=
 index=20
column should be stored there, from my point of view (yes I know it is =
a=20
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 q=
uestion=20
I have is, how you will manage case, when you set different values for =
same=20
options of different columns. like:

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

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


   =20

=2D-=20
Do code for fun.
--nextPart1749732.Q2npTO9Sal
Content-Type: application/pgp-signature; name="signature.asc"
Content-Description: This is a digitally signed message part.
Content-Transfer-Encoding: 7Bit

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2

iQEcBAABCAAGBQJb7qF5AAoJEKc13HowK+H46tcH/2MQN1BeRyT18q3NDno5vTQ7
xCKjhpbIcyoz1XmMw7ZiIRS6PsVeAdc6gX4FZp9qsWMYE0ubUxw7LvTpJLdLKbC4
yMXyoBrVeQ1Pj8uXdrNvfkHXn6UQ22bZFolcSQ5Jyxzww6gJlbouiNAdgGOfHBW6
rvM2mJE6C80EDg/WIIvB0fbD1+mMjnkNrga81XhJlUWC1TkxNswucexlG7Z4vMns
vtsvq92UBeIvEXKmAimWMFosOHANXouxxf5HmOyIlrkMm9SbIciXXCwIwPQfVTeq
aw6KMFVTTiDaUGdX5nDhkVpPIaYMMcYae3R0exnuqDk0wR4aY60mvOBN4CpmVLM=
=xOrw
-----END PGP SIGNATURE-----

--nextPart1749732.Q2npTO9Sal--