Обсуждение: Re: [COMMITTERS] pgsql: Add new variable "server_version_num", which is almost the same
momjian@postgresql.org (Bruce Momjian) writes:
> Add new variable "server_version_num", which is almost the same as
> "server_version" but uses the handy PG_VERSION_NUM which allows apps to
> do things like if ($version >= 80200) without having to parse apart the
> value of server_version themselves.
I thought this was rejected as being utterly useless. Or is this commit
somehow going to retroactively affect existing old servers?
A non-useless version of this would be client-side code ... except it's
already there, in libpq at least.
Please revert.
regards, tom lane
Tom Lane wrote: > momjian@postgresql.org (Bruce Momjian) writes: > > Add new variable "server_version_num", which is almost the same as > > "server_version" but uses the handy PG_VERSION_NUM which allows apps to > > do things like if ($version >= 80200) without having to parse apart the > > value of server_version themselves. > > I thought this was rejected as being utterly useless. Or is this commit > somehow going to retroactively affect existing old servers? You were the only one to object, as I remember. Others like it. The fact it was not in older releases was not a huge problem to them. We could actually backpatch it if we wanted. > A non-useless version of this would be client-side code ... except it's > already there, in libpq at least. There is no sense in having all clients reinvent this. I am not applying patches where everyone is going to agree to the feature. It only requires a majority. If you want a vote, we can do that. Same for the plpython patch. -- Bruce Momjian bruce@momjian.us EnterpriseDB http://www.enterprisedb.com + If your life is a hard drive, Christ can be your backup. +
I'd be less unhappy with this patch if the variable were not marked
GUC_REPORT. That is what gives it nontrivial cost: it's adding a couple
dozen bytes to every connection startup exchange, for data that's 100%
redundant with data already being transmitted.
The arguments that were made in favor of this patch cited its possible
use in SQL scripts, but there is no need for the variable to be marked
GUC_REPORT for that usage.
regards, tom lane
Tom Lane wrote: > I'd be less unhappy with this patch if the variable were not marked > GUC_REPORT. That is what gives it nontrivial cost: it's adding a couple > dozen bytes to every connection startup exchange, for data that's 100% > redundant with data already being transmitted. Wow, that is bad. > The arguments that were made in favor of this patch cited its possible > use in SQL scripts, but there is no need for the variable to be marked > GUC_REPORT for that usage. Agreed, will update. We can always change it later. -- Bruce Momjian bruce@momjian.us EnterpriseDB http://www.enterprisedb.com + If your life is a hard drive, Christ can be your backup. +
Tom Lane wrote: > I'd be less unhappy with this patch if the variable were not marked > GUC_REPORT. That is what gives it nontrivial cost: it's adding a couple > dozen bytes to every connection startup exchange, for data that's 100% > redundant with data already being transmitted. > > The arguments that were made in favor of this patch cited its possible > use in SQL scripts, but there is no need for the variable to be marked > GUC_REPORT for that usage. GUC_REPORT removed. -- Bruce Momjian bruce@momjian.us EnterpriseDB http://www.enterprisedb.com + If your life is a hard drive, Christ can be your backup. +