From: Nikolay Shaplov <n.shaplov@postgrespro.ru>
To: pgsql-hackers@postgresql.org
Subject: Re: [PROPOSAL] Move all am-related reloption code into
 src/backend/access/[am-name] and get rid of relopt_kind
Date: Fri, 27 May 2016 16:41:41 +0300
Message-ID: <1544707.j5kAjF95Mp@nataraj-amd64>
User-Agent: KMail/4.14.1 (Linux/3.16.0-4-amd64; KDE/4.14.2; x86_64; ; )
In-Reply-To: <4636505.Bu9AKW1Kzc@nataraj-amd64>
References: <4636505.Bu9AKW1Kzc@nataraj-amd64>
MIME-Version: 1.0
Content-Transfer-Encoding: quoted-printable
Content-Type: text/plain; charset="utf-8"
Precedence: bulk
Sender: pgsql-hackers-owner@postgresql.org

=D0=92 =D0=BF=D0=B8=D1=81=D1=8C=D0=BC=D0=B5 =D0=BE=D1=82 24 =D0=BC=D0=B0=D1=
=8F 2016 17:12:16 =D0=BF=D0=BE=D0=BB=D1=8C=D0=B7=D0=BE=D0=B2=D0=B0=D1=82=D0=
=B5=D0=BB=D1=8C Nikolay Shaplov =D0=BD=D0=B0=D0=BF=D0=B8=D1=81=D0=B0=D0=BB:

While working on this patch I met some difficulties that makes me to comple=
tely=20
rewrite a code that is responsible for interacting reloptions.c with access=
=20
methods.

Story start from the point that I found out that a.m. can not forbid changi=
ng=20
some of it's reloptions with ALTER INDEX command. That was not necessary=20=
=20
before, because all reloptions at that existed at that time can be changed =
on=20
fly. But now for bloom index it is unacceptable, because for changing bloom=
's=20
reloptions for existing index will lead to index malfunction.

I was thinking about adding for_alter flag argument for parseRelOptions fun=
tion=20
and pass it all the way from indexcmds.c & tablecmds.c, and add some flag i=
n=20
the definition of reloptions to mark those reloptions that should not be us=
ed=20
in ALTER INDEX clause.=20

This theoretically this will give us a way to throw error when user tries t=
o=20
change an reloption that should not be changed.

But unfortunately it turned out that in ATExecSetRelOptions new reloptions =
is=20
merged with existing reloptions values using transformRelOptions, and only=
=20
after that the result is sent for validation.=20

So on the step of the validation we can not distinguish old options from a =
new=20
one.=20

I've been thinking how to work this around, but found out that there is no=
=20
simple way. I can pass another array of flags through the whole call stack.=
 But=20
this make all thing uglier.=20

I can create another function that do pre-validation for new reloptions,=20
before doing final validation of the whole set. But this will make me to ha=
ve=20=20
to entities available from the a.m.: the descriptor of  reloptions and=20
function for custom validation of the results (i.e. like adjustBloomOptions=
=20
for Bloom).

But it would be not good if we dedicate two entires of a.m. to reoptions=20
definition. And there can be even more...=20

So I came to a conclusion: gather all the staff that defines the all the=20
behavior of reloption parsing and validation into one structure, both array=
 of=20
relopt_value, custom validation function, and all the other staff.

And this structure is the only thing that a.m. gives to reloptions.c code f=
or=20
parsing and validation purposes. And that should be enough.

I hope this make code more flexible and more easy to understand.


--=20
Nikolay Shaplov
Postgres Professional: http://www.postgrespro.com
Russian Postgres Company


--=20
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers