В Fri, 20 Sep 2019 20:58:27 +0900 Michael Paquier <mich...@paquier.xyz> пишет:
Sorry I am really slow to answer... I hope it is not too late. > The GUCs are also basically not necessary, as you can just replace the > various WARNING calls (please don't call elog on anything which can be > reached by the user!) by lookups at reloptions in pg_class. Once this > is removed, the whole code gets more simple, and there is no point in > having neither a separate header nor a different set of files and the > size of the whole module gets really reduced. Reading options from pg_class is not a good idea. We already do this in reloption regression test. Here the thing is almost same... My point of testing was to read these values from bytea right from inside of the module. This is not exactly the same value as in pg_class. It _should_ be the same. But nobody promised is _is_ the same. That is why I was reading it right from relotions in-memory bytea, the same way real access methods do it. And then we came to a GUC variables. Because it we have five reloptions and we print them all each time we change something, there would be quite huge output. It is ok when everything goes well. Comparing with 'expected' is cheap. But is something goes wrong, then it would be very difficult to find proper place in this output to deal with it. So I created GUCs so we can get only one output in a row, not a whole bunch. These are my points.
