Thread: Re: Rename Function: pg_postmaster_start_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.
>> 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 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.
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.
>This function has this name since 600da67fbe5e back from 2008.
>Changing that 16 years later will break things.
>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
than I initially realized. One possibility would be to create an
alias (or synonym) for the function "
pg_postmaster_start_time", naming it "
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.
pg_postgres_start_time". This way, the name changecould 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?
>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
it doesn't provide clarity on which specific configuration file or which configuration
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 namepg_conf_load_timedoesn't seem that confusing to me. However,
it doesn't provide clarity on which specific configuration file or which configurationwas "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 withme, of course, that we don't write PostgreSQL for ourselves, and good names shouldalways 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.
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