Received: from malur.postgresql.org ([217.196.149.56]) by arkaria.postgresql.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_CBC_SHA1:256) (Exim 4.89) (envelope-from ) id 1i5tuD-0008SF-In for pgsql-hackers@arkaria.postgresql.org; Thu, 05 Sep 2019 15:42:41 +0000 Received: from localhost ([127.0.0.1] helo=malur.postgresql.org) by malur.postgresql.org with esmtp (Exim 4.89) (envelope-from ) id 1i5tuC-00023p-An for pgsql-hackers@arkaria.postgresql.org; Thu, 05 Sep 2019 15:42:40 +0000 Received: from makus.postgresql.org ([2001:4800:3e1:1::229]) by malur.postgresql.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_CBC_SHA1:256) (Exim 4.89) (envelope-from ) id 1i5tuB-00023i-Ub; Thu, 05 Sep 2019 15:42:40 +0000 Received: from meldrar.postgresql.org ([2a02:c0:301:0:ffff::31]) by makus.postgresql.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_CBC_SHA1:256) (Exim 4.92) (envelope-from ) id 1i5tu9-0007nr-Af; Thu, 05 Sep 2019 15:42:38 +0000 DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=postgresql.org; s=20171124; h=In-Reply-To:Content-Transfer-Encoding: Content-Type:MIME-Version:Message-ID:Subject:Cc:To:From:Date:Sender:Reply-To: Content-ID:Content-Description:References; bh=10bLQAEKogU4VrrTh0yO69OD5ZAHYNq/HOgOChGfyZ8=; b=fPs+TOqB1XMidptXKE3qlz5ceO EUfNws/Giryf9r4Nsca3azAm28ZLkWMdaAVQZAo9Ak88ziVSRQSSNgawN/Jx3zw/SRJwmPGH3+uaX myg68039wmXESFLkGKjA33+Q841hztHCB9KRlY9OHP5reI0luH5iQn+xUBWzvq/S/j/nZfLaNU2Gj UNHYzbrkm8ckrAnsEbF6c0vtKc9LpMAe6+Hh1KG4/H+t8vfb8fwe0M0ESTkqlnsH0T6wyGsyFdNAC ZJoQdzoQIRUTVhvp4JjpjGrSpLb1Ld1E72KB+KFsebV23kAUbCXO/k+yJL3n7yYyZxSTMib+sqk11 /w0bqWVQ==; Received: from [190.121.29.3] (helo=nimloth.alvh.no-ip.org) by meldrar.postgresql.org with esmtpsa (TLS1.2:ECDHE_RSA_AES_256_CBC_SHA1:256) (Exim 4.89) (envelope-from ) id 1i5tu5-0002oH-4V; Thu, 05 Sep 2019 15:42:35 +0000 Received: by nimloth.alvh.no-ip.org (Postfix, from userid 1000) id 48FC2123D16; Thu, 5 Sep 2019 11:42:27 -0400 (-04) Date: Thu, 5 Sep 2019 11:42:27 -0400 From: Alvaro Herrera from 2ndQuadrant To: Nikolay Shaplov Cc: pgsql-hackers@lists.postgresql.org, Tom Lane , Robert Haas , Nikita Glukhov , "pgsql-hackers@postgresql.org" Subject: Re: [PATCH][PROPOSAL] Add enum releation option type Message-ID: <20190905154227.GA5287@alvherre.pgsql> MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: <15941756.bfKRYTai5T@x200m> User-Agent: Mutt/1.9.4 (2018-02-28) X-Host-Lookup-Failed: Reverse DNS lookup failed for 190.121.29.3 (failed) List-Id: List-Help: List-Subscribe: List-Post: List-Owner: List-Archive: Precedence: bulk After looking closer once again, I don't like this patch. I think the FOOBAR_ENUM_DEF defines serve no purpose, other than source-code placement next to the enum value definitions. I think for example check_option, living in reloptions.c, should look like this: { { "check_option", "View has WITH CHECK OPTION defined (local or cascaded).", RELOPT_KIND_VIEW, AccessExclusiveLock }, { { "local", VIEW_OPTION_CHECK_OPTION_LOCAL }, { "cascaded", VIEW_OPTION_CHECK_OPTION_CASCADED }, { NULL } }, "Valid values are \"local\" and \"cascaded\"." }, Note the relopt_enum is pretty much the same you have, except we also have a const char *valid_values_errdetail; and the ugly #define no longer exists but instead we put it in enumRelOpts. rel.h ends up like this: /* * Values for ViewOptions->check_option. */ typedef enum { VIEWOPTIONS_CHECK_OPTION_NOTSET, VIEWOPTIONS_CHECK_OPTION_LOCAL, VIEWOPTIONS_CHECK_OPTION_CASCADED } ViewOpts_CheckOptionValues; /* * ViewOptions * Contents of rd_options for views */ typedef struct ViewOptions { int32 vl_len_; /* varlena header (do not touch directly!) */ bool security_barrier; ViewOpts_CheckOptionValues check_option; } ViewOptions; I'm marking this Waiting on Author. -- Álvaro Herrera https://www.2ndQuadrant.com/ PostgreSQL Development, 24x7 Support, Remote DBA, Training & Services