On Sat, Apr 18, 2020 at 10:43:52AM -0400, Robert Haas wrote: > I'm not in favor of this renaming. Different people have different > preferences, of course, but my impression is that the general project > style is to choose names that follow English word ordering, i.e. > appendStringInfo rather than stringInfoAppend; add_paths_to_joinrel > rather than joinrel_append_paths; etc. There are many exceptions, but > I tend to lean toward English word ordering unless it seems to create > a large amount of awkwardness in a particular case. At any rate, it > seems a separate question from moving the code.
Both of us have rather different views on the matter then. I still prefer my suggestion because that's more consistent and easier to grep, but I'll be fine with your call at the end. I would suggest to still use BackupManifest instead of Manifest in those functions and structures though, as we cannot really know if the concept of manifest would apply to other parts of the system. A recent example of API name conflict I have in mind is index AM vs table AM. Index AMs have been using rather generic names, causing issues when table AMs have been introduced. > I'm OK with that. I don't think it's a big deal because "manifest" > isn't a widely-used PostgreSQL term already, but it doesn't bother me > to rename it. Thanks. -- Michael
signature.asc
Description: PGP signature
