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