pg.ddx.io  pgsql-hackers@postgresql.org mailing list archive  
help / color / mirror / Atom feed
From: Alvaro Herrera <alvherre@alvh.no-ip.org>
To: Nikolay Shaplov <dhyan@nataraj.su>
Cc: pgsql-hackers@lists.postgresql.org
Cc: pgsql-hackers@postgresql.org
Subject: Re: [PATCH][PROPOSAL] Add enum releation option type
Date: Thu, 15 Feb 2018 12:53:27 -0300
Message-ID: <20180215155327.52suiqdcf3f4z3ir@alvherre.pgsql> (raw)
In-Reply-To: <29235994.NprrEGRed4@x200m>

Nikolay Shaplov wrote:
> В письме от 9 февраля 2018 18:45:29 пользователь Alvaro Herrera написал:
> 
> > Maybe we need some in-core user to verify the string case still works.
> > A new module in src/test/modules perhaps? 
> I've looked attentively in src/test/modules... To properly test all reloptions 
> hooks for modules wee need to create an extension with some dummy index in it. 
> This way we can properly test everything. Creating dummy index would be fun, 
> but it a quite big deal to create it, so it will require a separate patch to 
> deal with. So I suppose string reloptions is better to leave untested for now, 
> with a notion, that it should be done sooner or later

Do we really need a dummy index?  I was thinking in something that just
calls a few C functions to create and parse a string reloption should be
more than enough.

> > I don't much like the way you've represented the list of possible values
> > for each enum.  I think it'd be better to have a struct that represents
> > everything about each value (string name and C symbol.  Maybe the
> > numerical value too if that's needed, but is it?  I suppose all code
> > should use the C symbol only, so why do we care about the numerical
> > value?).
> One more reason to keep numeric value, that came to my mind, is that it seems 
> to be logical to keep enum value in postgres internals represented as C-enum. 
> And C-enum is actually an int value (can be easily casted both ways). It is 
> not strictly necessary, but it seems to be a bit logical... 

Oh, I didn't mean to steer you away from a C enum.  I just meant that we
don't need to define the numerical values ourselves -- it should be fine
to use whatever the C compiler chooses for each C symbol (enum member
name).  In the code we don't refer to the values by numerical value,
only by the C symbol.

-- 
Álvaro Herrera                https://www.2ndQuadrant.com/
PostgreSQL Development, 24x7 Support, Remote DBA, Training & Services




view thread (40+ messages)  latest in thread

Message-ID: <20180215155327.52suiqdcf3f4z3ir@alvherre.pgsql>
Permalink:  ../20180215155327.52suiqdcf3f4z3ir@alvherre.pgsql/
Also on:    postgresql.org/message-id/20180215155327.52suiqdcf3f4z3ir@alvherre.pgsql

 · 

reply

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Reply to all the recipients using the --to and --cc options:
  reply via email

  To: pgsql-hackers@postgresql.org
  Cc: alvherre@alvh.no-ip.org, dhyan@nataraj.su, pgsql-hackers@lists.postgresql.org
  Subject: Re: [PATCH][PROPOSAL] Add enum releation option type
  In-Reply-To: <20180215155327.52suiqdcf3f4z3ir@alvherre.pgsql>

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

This inbox is served by DDX for PostgreSQL; see mirroring instructions
for how to clone and mirror all data and code used for this inbox