I have never heard of coding standards where naming conventions required a function/variable name match a directory or file name. It seems that would be restrictive.
This is not about coding standard, this is about terminology and common sense.
I'm not trying to pick a fight, I just think the pros should outweigh the cons when choosing a path forward. In this case I see lots of cons and one partial pro; partial because renaming only user facing functions and documentation will create inconsistency within the Postgres code for all of the following. It sounds as if your minds are already made up, which saddens me but I will say nothing further on the matter.
Ultimately, from user/dba perspective code does not matter. Consistency does. I found out firsthand that the fact pg_swicth_xlog() does something in pg_wal directory is rather confusing.
The way I see it decision has been made to rename 'pg_xlog' to 'pg_wal'. Since this directory name is effectively part of API (e.g. for setups with xlog on different disk, backup scripts, etc), rest of API either needs to follow or this decision needs to be revised (but that ship has probably sailed).
I think small inconvenience of a small group of people (PostgreSQL developers) is worth the improvement for much larger group of people (PostgreSQL users).
Now, I'm not sure whether it is worth maintaining function aliases. Assuming these are indeed trivial (can somebody point me to example?) I see roughly the same amount of downsides both ways.
Having aliases raises additional questions:
- do we keep them documented (probably not?)
- do we keep them forever or kill in some future version?
-- Vladimir Rusinov Storage SRE, Google Ireland
Google Ireland Ltd.,Gordon House, Barrow Street, Dublin 4, Ireland Registered in Dublin, Ireland Registration Number: 368047
