On Thu, Dec 29, 2016 at 5:48 PM, Cynthia Shang <
cynthia.sh...@crunchydata.com> wrote:

> 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

> 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
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

Attachment: smime.p7s
Description: S/MIME Cryptographic Signature

Reply via email to