Rename Function: pg_postmaster_start_time
Hi!
I have been working on some servers that haven't been shut down or restarted for many days. As a result, the need arose to use the function 'pg_postmaster_start_time' (which I had completely forgotten existed).
While working with it, I realized that it would be more appropriate for its name to be 'pg_postgres_start_time', to align with the name of the main process displayed by the operating system. The process, which was previously known as "postmaster," has long been referred to as "postgres".
I suggest this change to simplify the terminology and make the function name more intuitive, as "postgres" directly refers to the database server. This seems more suitable to me.
Attached is the patch with the suggest adjustment.
Result:
[postgres@192 bin]$ pwd
/pgsql18devel/18devel_bin/bin
[postgres@192 bin]$ ./psql -p 5454 -h ::1
psql (18devel)
Type "help" for help.
postgres=# select pg_postgres_start_time();
pg_postgres_start_time
-------------------------------
2024-11-05 14:52:42.463293-03
(1 row)
Regards,
Maiquel Grassi.
Attachments:
v1-0001-Rename-pg_postmaster_start_time_function.patchtext/x-patch; name=v1-0001-Rename-pg_postmaster_start_time_function.patchDownload
diff --git a/doc/src/sgml/func.sgml b/doc/src/sgml/func.sgml
index 73979f20ff..44285ab393 100644
--- a/doc/src/sgml/func.sgml
+++ b/doc/src/sgml/func.sgml
@@ -24816,9 +24816,9 @@ SELECT * FROM pg_ls_dir('.') WITH ORDINALITY AS t(ls,n);
<row>
<entry role="func_table_entry"><para role="func_signature">
<indexterm>
- <primary>pg_postmaster_start_time</primary>
+ <primary>pg_postgres_start_time</primary>
</indexterm>
- <function>pg_postmaster_start_time</function> ()
+ <function>pg_postgres_start_time</function> ()
<returnvalue>timestamp with time zone</returnvalue>
</para>
<para>
diff --git a/src/backend/utils/adt/timestamp.c b/src/backend/utils/adt/timestamp.c
index e00cd3c969..7b176a4970 100644
--- a/src/backend/utils/adt/timestamp.c
+++ b/src/backend/utils/adt/timestamp.c
@@ -49,7 +49,7 @@
#define SAMESIGN(a,b) (((a) < 0) == ((b) < 0))
-/* Set at postmaster start */
+/* Set at postgres start */
TimestampTz PgStartTime;
/* Set at configuration reload */
@@ -1623,7 +1623,7 @@ clock_timestamp(PG_FUNCTION_ARGS)
}
Datum
-pg_postmaster_start_time(PG_FUNCTION_ARGS)
+pg_postgres_start_time(PG_FUNCTION_ARGS)
{
PG_RETURN_TIMESTAMPTZ(PgStartTime);
}
diff --git a/src/include/catalog/pg_proc.dat b/src/include/catalog/pg_proc.dat
index f23321a41f..052dbe1548 100644
--- a/src/include/catalog/pg_proc.dat
+++ b/src/include/catalog/pg_proc.dat
@@ -8587,9 +8587,9 @@
# start time function
{ oid => '2560', descr => 'postmaster start time',
- proname => 'pg_postmaster_start_time', provolatile => 's',
+ proname => 'pg_postgres_start_time', provolatile => 's',
prorettype => 'timestamptz', proargtypes => '',
- prosrc => 'pg_postmaster_start_time' },
+ prosrc => 'pg_postgres_start_time' },
# config reload time function
{ oid => '2034', descr => 'configuration load time',
On Tue, Nov 5, 2024 at 11:26 AM Maiquel Grassi <grassi@hotmail.com.br>
wrote:
I suggest this change to simplify the terminology and make the function
name more intuitive, as "postgres" directly refers to the database server.
This seems more suitable to me.
Seems like an unnecessary change of a publicly facing feature. IMO
stability wins out over any debatable improvement the change may bring.
David J.
I suggest this change to simplify the terminology and make the function
name more intuitive, as "postgres" directly refers to the database server.
This seems more suitable to me.
Seems like an unnecessary change of a publicly facing feature. IMO
stability wins out over any debatable improvement the change may bring.
There are several parts of the system where the term 'postmaster' appears and could potentially be changed to 'postgres'. In most cases, I agree with you: keeping the current term is a more cautious approach and ensures stability. However, in the case of this function, the adjustment is quite simple and doesn’t involve significant changes to the files; it’s really just a matter of 'replacing' the term.
Regards,
Maiquel Grassi.
On Tue, Nov 5, 2024 at 11:59 AM Maiquel Grassi <grassi@hotmail.com.br>
wrote:
I suggest this change to simplify the terminology and make the function
name more intuitive, as "postgres" directly refers to the databaseserver.
This seems more suitable to me.
Seems like an unnecessary change of a publicly facing feature. IMO
stability wins out over any debatable improvement the change may bring.There are several parts of the system where the term 'postmaster' appears
and could potentially be changed to 'postgres'. In most cases, I agree with
you: keeping the current term is a more cautious approach and ensures
stability. However, in the case of this function, the adjustment is quite
simple and doesn’t involve significant changes to the files; it’s really
just a matter of 'replacing' the term.
The ease or difficulty of making the change in the server has no meaningful
bearing on whether breaking this public API is warranted or not.
David J.
On Tue, Nov 05, 2024 at 12:05:11PM -0700, David G. Johnston wrote:
The ease or difficulty of making the change in the server has no meaningful
bearing on whether breaking this public API is warranted or not.
This function has this name since 600da67fbe5e back from 2008.
Changing that 16 years later will break things.
--
Michael
This function has this name since 600da67fbe5e back from 2008.
Changing that 16 years later will break things.
Certainly, there are more considerations to take into account
than I initially realized. One possibility would be to create an
alias (or synonym) for the function "pg_postmaster_start_time",
naming it "pg_postgres_start_time". This way, the name change
could occur gradually and strategically over the coming years,
without immediate impact. I believe this approach could be
viable to facilitate a future transition without abrupt breaks.
Maiquel
On 6 Nov 2024, at 20:28, Maiquel Grassi <grassi@hotmail.com.br> wrote:
This function has this name since 600da67fbe5e back from 2008.
Changing that 16 years later will break things.Certainly, there are more considerations to take into account
than I initially realized. One possibility would be to create an
alias (or synonym) for the function "pg_postmaster_start_time",
naming it "pg_postgres_start_time". This way, the name change
could occur gradually and strategically over the coming years,
without immediate impact. I believe this approach could be
viable to facilitate a future transition without abrupt breaks. Maiquel
I can agree that pg_postmaster_ has the potential to be confusing to users, but
I agree that if we are to do anything it should be alias while maintaining the
old name for compatibility.
Looking at similar functions it's clear they don't use the pg_postgres_ prefix,
like for example pg_conf_load_time. Should this if so be pg_start_time?
--
Daniel Gustafsson
I can agree that pg_postmaster_ has the potential to be confusing to users, but
I agree that if we are to do anything it should be alias while maintaining the
old name for compatibility.Looking at similar functions it's clear they don't use the pg_postgres_ prefix,
like for example pg_conf_load_time. Should this if so be pg_start_time?
The name pg_conf_load_time doesn't seem that confusing to me. However,
it doesn't provide clarity on which specific configuration file or which configuration
was "reloaded," so depending on the user sitting behind the computer, it could
indeed, be considered confusing as well. I wouldn't know how to suggest a better
alias for this function, "pg_conf_load_time." I like to always remind that PostgreSQL
is written for users, not for us. The current names and terms are very clear to us, actually,
extremely clear. For someone here in the hacker community, saying "postgres" or
"postmaster" is irrelevant — we are all more than advanced users of PostgreSQL, but we
are the minority of minorities within the range of users worldwide who use PostgreSQL.
Well, in that sense, I honestly only thought of a better and less confusing name for
"pg_postmaster_start_time." For the other functions that may have poor names,
I haven't done an assessment. I don't have a suggestion for your point, maybe someone
else does. The idea of using aliases would be a long-term solution, if you agree with
me, of course, that we don't write PostgreSQL for ourselves, and good names should
always be considered with the end users in mind.
Maiquel
On Wed, Nov 6, 2024 at 1:17 PM Maiquel Grassi <grassi@hotmail.com.br> wrote:
I can agree that pg_postmaster_ has the potential to be confusing to
users, but
I agree that if we are to do anything it should be alias while
maintaining the
old name for compatibility.
Looking at similar functions it's clear they don't use the pg_postgres_
prefix,
like for example pg_conf_load_time. Should this if so be pg_start_time?
The name pg_conf_load_time doesn't seem that confusing to me. However,
it doesn't provide clarity on which specific configuration file or which
configuration
was "reloaded,"
Since it reloads "all" of them such specificity would not be warranted.
This is actually a problem for pg_start_time though, especially if it stays
in the table "Session Information Functions" since one would rightly assume
it returns the time this client-session process started, not the postmaster
process.
The idea of using aliases would be a long-term solution, if you agree with
me, of course, that we don't write PostgreSQL for ourselves, and good
names should
always be considered with the end users in mind.
Except it doesn't seem like users are confused. It is just someone in the
ivory tower thinking they could be. It feels like make-work for a problem
that doesn't actually exist.
So even agreeing with you that naming for comprehension by users is
important this change doesn't seem necessary. If they see the name in the
documentation and are confused by the terminology "postmaster" maybe we can
cross-reference the glossary where it is defined.
This is a function that is likely often executed in third-party scripts and
not that often executed manually. That further increases the burden of
change, especially relative to memorization burden for a user typing it in
manually.
David J.
Except it doesn't seem like users are confused. It is just someone in the ivory tower thinking they could be. It feels like make-work for a problem that doesn't actually exist.
Hello. I understand that this type of comment could be interpreted as
discouraging and detrimental to the development of new ideas and
the growth of the community as a whole. I recognize that your
perspective has great value in helping to identify potential situations
that may not be viable. However, I would like to suggest that the way
these issues are expressed publicly could be more careful to avoid
misunderstandings.
Maiquel.
Daniel Gustafsson <daniel@yesql.se> writes:
Looking at similar functions it's clear they don't use the pg_postgres_ prefix,
like for example pg_conf_load_time. Should this if so be pg_start_time?
No, because it's not clear what start time you're talking about;
aside from the postmaster, this could plausibly refer to the
session start, transaction start, or query start time.
Like David, I'm not seeing a good argument for changing anything
here.
regards, tom lane