Re: relocating the server's backup manifest code

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