Re: [PATCH][PROPOSAL] Add enum releation option type

From: Alvaro Herrera from 2ndQuadrant <alvherre(at)postgresql(dot)org>
To: Nikolay Shaplov <dhyan(at)nataraj(dot)su>
Cc: pgsql-hackers(at)lists(dot)postgresql(dot)org, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>, Robert Haas <robertmhaas(at)gmail(dot)com>, Nikita Glukhov <n(dot)gluhov(at)postgrespro(dot)ru>, "pgsql-hackers(at)postgresql(dot)org" <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: [PATCH][PROPOSAL] Add enum releation option type
Date: 2019-09-05 15:42:27
Message-ID: 20190905154227.GA5287@alvherre.pgsql
Views: Raw Message | Whole Thread | Download mbox | Resend email
Lists: pgsql-hackers

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:

"View has WITH CHECK OPTION defined (local or 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
} 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
PostgreSQL Development, 24x7 Support, Remote DBA, Training & Services

In response to


Browse pgsql-hackers by date

  From Date Subject
Next Message Tom Lane 2019-09-05 15:53:31 Re: CVE-2017-7484-induced bugs, or, btree cmp functions are not leakproof?
Previous Message Alvaro Herrera from 2ndQuadrant 2019-09-05 15:25:02 Re: [PATCH] Add support for ON UPDATE/DELETE actions on ALTER CONSTRAINT