[HACKERS] [PATCH] Tests for reloptions
От | Nikolay Shaplov |
---|---|
Тема | [HACKERS] [PATCH] Tests for reloptions |
Дата | |
Msg-id | 2615372.orqtEn8VGB@x200m обсуждение исходный текст |
Ответы |
Re: [HACKERS] [PATCH] Tests for reloptions
|
Список | pgsql-hackers |
This thread continues discussion at https://www.postgresql.org/message-id/20170903094543.kkqdbdjuxwa5z6ji@alvherre.pgsql (Shortly: I refactored reloptions code, Alvaro offered to commit tests before the full patch) > I see that this patch adds a few tests for reloptions, for instance in > bloom. I think we should split this in at least two commits, one that > adds those tests before the functionality change, so that they can be > committed in advance, verify that the buildfarm likes it with the > current code, and verify the coverage. This sounds as a really good idea. Though I have several questions. This tests also covers some functionality that were introduced only in my patch: 1. Forbid SET and RESET options where they should not be changed 2. Forbid creating tables with toasts options when no toast table is created 3. Split StdRdOptions into HeapOptions and ToastOptions and forbid uising Heap specific options for toast. In the patch I've attached I've commented out this functionality. But I am not quite sure that it is good idea to commit it this way in master. May be it would be good to make 1-3 as a separate patches and bring it's tests with, as a separate commit. But... 2nd can be easily ported to master. It does not depend much on my reloptions patch as far as I remember. It would be insane to port 1st feature to master. It highly integrated with reloptions mechanism, It would require complete reimplementation of this feature using old reloptions tools. I totally do not want to do it The 3rd functionality came from philosophy one relation-type -- one options catalog, that was implemented in my reloptions patch. It is not really needed in master without the full patch. With some efforts I think it can be made as a separate patch, thought I would also try to avoid it if possible. So the questions still is: should we commit not existent functionality tests commented, uncomented but with no proper error response in expected output, or just remove these tests from this patch? -- Do code for fun. Can do it for money (Perl & C/C++ ~10h/week) -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Вложения
В списке pgsql-hackers по дате отправления: