В письме от среда, 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.