[PATCH] Tests for reloptions

From: Nikolay Shaplov <dhyan(at)nataraj(dot)su>
To: pgsql-hackers(at)postgresql(dot)org
Cc: Alvaro Herrera <alvherre(at)alvh(dot)no-ip(dot)org>, Andres Freund <andres(at)anarazel(dot)de>
Subject: [PATCH] Tests for reloptions
Date: 2017-09-05 09:41:34
Message-ID: 2615372.orqtEn8VGB@x200m
Views: Raw Message | Whole Thread | Download mbox
Thread:
Lists: 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)

Attachment Content-Type Size
relopt_tests_v1a.diff text/x-patch 32.3 KB

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Amit Kapila 2017-09-05 09:52:41 Re: WIP: long transactions on hot standby feedback replica / proof of concept
Previous Message Chris Travers 2017-09-05 09:31:07 Re: Proposal: pg_rewind to skip config files