From: | Nikolay Shaplov <dhyan(at)nataraj(dot)su> |
---|---|
To: | Alvaro Herrera <alvherre(at)2ndquadrant(dot)com> |
Cc: | pgsql-hackers(at)lists(dot)postgresql(dot)org, Dmitry Dolgov <9erthalion6(at)gmail(dot)com> |
Subject: | Re: [PATCH] get rid of StdRdOptions, use individual binary reloptions representation for each relation kind instead |
Date: | 2019-01-02 09:58:15 |
Message-ID: | 3035684.rZsmX32AVU@x200m |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
В письме от среда, 2 января 2019 г. 0:05:10 MSK пользователь Alvaro Herrera
написал:
> One thing I would like to revise here is to avoid unnecessary API change
> -- for example the RelationHasCascadedCheckOption macro does not really
> need to be renamed because it only applies to views, so there's no
> possible conflict with other relation types. We can keep the original
> name and add a StaticAssert that the given relation is indeed a view.
> This should keep churn somewhat low. Of course, this doesn't work for
> some options where you need a different one for different relation
> kinds, such as fillfactor, but that's unavoidable.
My intention was to make API names more consistent. If you are addressing View
specific option, it is good to address it via View[Something] macros or
function. Relations[Something] seems to be a bad name, since we are dealing
not with any relation in general, but with a view relation.
This is internal API, right? If we change it everywhere, then it is changed
and nothing will be broken?
May be it may lead to problems I am unable to see, but I still unable to see
them so I can't make any judgment about it.
If you insist (you have much more experience than I) I would do as you advise,
but still I do not understand.
From | Date | Subject | |
---|---|---|---|
Next Message | Petr Jelinek | 2019-01-02 10:02:22 | Re: Connection slots reserved for replication |
Previous Message | Oleksii Kliukin | 2019-01-02 09:21:56 | Re: Connection slots reserved for replication |