... and of course the other functions matching *wal*location* My thoughts here are that we're already breaking backward compatibility of these functions for PG10, so thought we might want to use this as an opportunity to fix the naming a bit more.
I feel that the "location" word not the best choice. We also have a function called pg_tablespace_location() to give us the path that a tablespace is stored in, so I could understand anyone who's confused about what pg_current_wal_location() might do if they're looking at the function name only, and not the docs. For me, "lsn" suits these function names much better, so I'd like to see what other's think. It would be sad to miss this opportunity without at least discussing this first. The functions in question are: postgres=# \dfS *wal*location* List of functions Schema | Name | Result data type | Argument data types | Type ------------+--------------------------------+------------------+---------------------+-------- pg_catalog | pg_current_wal_flush_location | pg_lsn | | normal pg_catalog | pg_current_wal_insert_location | pg_lsn | | normal pg_catalog | pg_current_wal_location | pg_lsn | | normal pg_catalog | pg_last_wal_receive_location | pg_lsn | | normal pg_catalog | pg_last_wal_replay_location | pg_lsn | | normal pg_catalog | pg_wal_location_diff | numeric | pg_lsn, pg_lsn | normal (6 rows) Opinions? -- David Rowley http://www.2ndQuadrant.com/ PostgreSQL Development, 24x7 Support, Training & Services -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers