В письме от 1 марта 2018 16:15:32 пользователь Andres Freund написал:

> > This is part or my bigger patch
> > https://www.postgresql.org/message-id/flat/2146419.veIEZdk4E4@x200m#21464
> > 19.veIEZdk4E4@x200m we've decided to commit by smaller parts.
> I've not read that thread. Is this supposed to be a first step towards
> something larger?

I've started from the idea of opclass options. Same as here 
And found out that current reloptions code is not flexible at all, and could 
not be easily reused for other kind of options (that are not reloptions).

So I tried to change reloptions code to make universal, and then use it for 
any option purposes.

In the patch https://commitfest.postgresql.org/14/992/ I created a new file 
options.c, that works with options as with an abstraction. It has some option 
definition structure, that has all information about how this options should 
be parsed and transformed into binary representation, I called this structure 
OptionsCatalog, but name can be changed. And it also have all kind of 
functions that do all needed tranformation with options.

Then reloptions.c uses functions from options options.c for all options 
transformations, and takes care about relation specificity of reloptions.

While doing all of these, I first of all had to adjust code that was written 
around reloptions, so that there code would stay in tune with new reloptions 
code. And second, I met places where current reloption related code were 
imperfect, and I decided to change it too...

Since I get a really big patch as a result, it was decided to commit it in 

This patch is the adjusting of reloption related code. It does not change a 
great deal, but when you first commit it, the main reloptions refactoring 
patch will no longer look like a big mess, it will became much more logical.

Enum options patch is more about making coder a little bit more perfect. It is 
not really needed for the main patch, but it is more easy to introduce it 
before, then after.

There is one more patch, that deals with toast.* options for tables with no 
TOAST, but we can set it aside, it is independent enough, to deal with it 

The patch with reloptions tests I've written while working on this patch, were 
already commited

> > So for example if you set custom fillfactor value for some index, then it
> > will lead to allocating 84 bytes of memory (sizeof StdRdOptions on i386)
> > and only 8 bytes will be actually used (varlena header and fillfactor
> > value). 74 bytes is not much, but allocating them for each index for no
> > particular reason is bad idea, as I think.
> I'm not sure this is a particularly strong motivator though?  Does the
> patch have a goal besides saving a few bytes?

My real motivation for this patch is to make code more uniform. So the patch 
over it will be much clearer. And to make result code more clear and uniform 

I guess long time ago, the StdRdOptions were the way to make code uniform. 
There were only one binary representation of options, and all relation were 
using it. Quite uniform.

But now, some relation kinds uses it's own options binary representations. 
Some still uses StdRdOptions, but only some elements from it. It is not 
uniform enough for me.

If start using individual binary representation for each relation kind, then 
code will be uniform and homogeneous again, and my next patch over it will be 
more easy to read and understand. 

> > Moreover when I wrote my big reloption refactoring patch, I came to "one
> > reloption kind - one binary representation" philosophy. It allows to write
> > code with more logic in it.
> I have no idea what this means?
I hope I managed to explain it above... May be I am not good enough with 
explaining, or with English. Or with explaining in English. If it is not clear 
enough, please tell me, what points are not clear, I'll try to explain more...

> Are you aiming this for v11 or v12?
I hope to commit StdRdOptions and Enum_Options patches before v11. 
Hope it does not go against any rules, since there patches does not change any 
big functionality, just do some refactoring and optimization, of the code that 
already exists.

As for main reloptions refactoring patch, if there is a chance to get commited 
before v11 release, it would be great. If not, I hope to post it to 
commitfest, right after v11 were released, so it would be possible to commit 
opclass options upon it before v12 release. 

Do code for fun.

Attachment: signature.asc
Description: This is a digitally signed message part.

Reply via email to