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