Обсуждение: [GENERAL] Naming conventions for column names
Hi All,
Is there any reason to keep column names as usesysid and senate instead of usersysid and username ?
postgres=# select * from pg_stat_replication ;
pid | usesysid | usename | application_name | client_addr | client_hostname | client_port | backend_start | backend_xmin | stat
e | sent_location | write_location | flush_location | replay_location | sync_priority | sync_state
------+----------+---------+------------------+---------------+-----------------+-------------+-------------------------------+--------------+-------
----+---------------+----------------+----------------+-----------------+---------------+------------
2297 | 24522 | replica | walreceiver | 192.168.16.53 | | 49782 | 2017-08-15 00:45:43.256404-04 | 149384444 | stream
ing | 111/BD9D5328 | 111/BD9D5328 | 111/BD9D5328 | 111/BD9D52F0 | 0 | async
(1 row)
Sachin Kotwal
Hi All,
Correcting my words.
Is there any special reason to keep column names as usesysid and usename instead of usersysid and username in below system View?
On Mon, Nov 6, 2017 at 4:03 PM, Sachin Kotwal <kotsachin@gmail.com> wrote:
Hi All,Is there any reason to keep column names as usesysid and senate instead of usersysid and username ?postgres=# select * from pg_stat_replication ;pid | usesysid | usename | application_name | client_addr | client_hostname | client_port | backend_start | backend_xmin | state | sent_location | write_location | flush_location | replay_location | sync_priority | sync_state------+----------+---------+------------------+------------- --+-----------------+--------- ----+------------------------- ------+--------------+------- ----+---------------+----------------+----------------+----- ------------+---------------+- ----------- 2297 | 24522 | replica | walreceiver | 192.168.16.53 | | 49782 | 2017-08-15 00:45:43.256404-04 | 149384444 | streaming | 111/BD9D5328 | 111/BD9D5328 | 111/BD9D5328 | 111/BD9D52F0 | 0 | async(1 row)--Thanks and Regards,Sachin Kotwal
Sachin Kotwal
On 11/6/17 05:36, Sachin Kotwal wrote: > Is there any special reason to keep column names as usesysid > and usename instead of usersysid and username in below system View? The reason to *keep* them is compatibility. The reason they are like that to start with is because that is the naming pattern used in the system catalogs: 3 letters indicating the catalog, plus additional letters or words. It is useful to use the same name in views such as pg_stat_replication, so you can easily join different views and catalogs. -- Peter Eisentraut http://www.2ndQuadrant.com/ PostgreSQL Development, 24x7 Support, Remote DBA, Training & Services -- Sent via pgsql-general mailing list (pgsql-general@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-general
Hi Peter,
I can understand that it is important to maintain naming pattern same as system catalogs, but in that case we may need to redefine system catalogs naming conventions .
So that we can use those newly added naming conventions in system views as well.
It is difficult to understand usename = database user name and usesysid = system user id.
It is better to use full names to those columns, so that Users can easily understand those columns by their names.
In this case adding one or more laters will not cause any problem but will add more readability.
In case adding 3 letters indicating the catalog , can we use 4 or 5 letters ?
I think we need to rethink about these short naming conventions which are making confusion, If community is ok with that.
Please share yours thoughts on this.
Regards,
Sachin Kotwal
On Mon, Nov 6, 2017 at 6:21 PM, Peter Eisentraut <peter.eisentraut@2ndquadrant.com> wrote:
On 11/6/17 05:36, Sachin Kotwal wrote:
> Is there any special reason to keep column names as usesysid
> and usename instead of usersysid and username in below system View?
The reason to *keep* them is compatibility. The reason they are like
that to start with is because that is the naming pattern used in the
system catalogs: 3 letters indicating the catalog, plus additional
letters or words. It is useful to use the same name in views such as
pg_stat_replication, so you can easily join different views and catalogs.
--
Peter Eisentraut http://www.2ndQuadrant.com/
PostgreSQL Development, 24x7 Support, Remote DBA, Training & Services
Sachin Kotwal
Sachin Kotwal <kotsachin@gmail.com> writes:
> I can understand that it is important to maintain naming pattern same as
> system catalogs, but in that case we may need to redefine system catalogs
> naming conventions .
Those naming conventions are twenty-five years old, and there is an
astonishing amount of client code that would break if we ran around
changing existing system catalog column names. It's very unlikely that
any proposal to do that would even receive serious consideration.
The bar to using new naming conventions in new catalogs would be
lower, of course, but then you have to think about the confusion
factor of having different naming styles in different places.
regards, tom lane
--
Sent via pgsql-general mailing list (pgsql-general@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-general
>Those naming conventions are twenty-five years old, and there is an >astonishing amount of client code that would break if we ran around >changing existing system catalog column names. It's very unlikely that >any proposal to do that would even receive serious consideration. >The bar to using new naming conventions in new catalogs would be >lower, of course, but then you have to think about the confusion >factor of having different naming styles in different places. Isn't there a word for the above : Technology debt :-) -- Sent via pgsql-general mailing list (pgsql-general@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-general
Hi Tom,
You are right. Those naming conventions are old and that is why we have to improve those where ever and when ever required.
If no one has objection, I will give a try to improve this part.
I believe these naming conventions will be at two levels:
1. Internal code of PostgreSQL , structures getting used internally
2. SQL/C functions get executed at the time of database initialization to create default objects and system catalogs.
I will see how much modifications/efforts need to be done and will come back again if it is feasible.
My intension is to improve naming conventions and increase naming string where naming conventions are correct but make shorten.
Suggestions and feedbacks are welcome.
Regards,
Sachin Kotwal
On Mon, Nov 6, 2017 at 8:03 PM, Tom Lane <tgl@sss.pgh.pa.us> wrote:
Sachin Kotwal <kotsachin@gmail.com> writes:
> I can understand that it is important to maintain naming pattern same as
> system catalogs, but in that case we may need to redefine system catalogs
> naming conventions .
Those naming conventions are twenty-five years old, and there is an
astonishing amount of client code that would break if we ran around
changing existing system catalog column names. It's very unlikely that
any proposal to do that would even receive serious consideration.
The bar to using new naming conventions in new catalogs would be
lower, of course, but then you have to think about the confusion
factor of having different naming styles in different places.
regards, tom lane
Sachin Kotwal
On Mon, Nov 06, 2017 at 08:23:07PM +0530, Sachin Kotwal wrote: > You are right. Those naming conventions are old and that is why we have to > improve those where ever and when ever required. I'd love to see the "requirement" defined. Regards, Karsten -- GPG key ID E4071346 @ eu.pool.sks-keyservers.net E167 67FD A291 2BEA 73BD 4537 78B9 A9F9 E407 1346 -- Sent via pgsql-general mailing list (pgsql-general@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-general
On Mon, Nov 6, 2017 at 10:04 AM, Karsten Hilbert <Karsten.Hilbert@gmx.net> wrote:
On Mon, Nov 06, 2017 at 08:23:07PM +0530, Sachin Kotwal wrote:
> You are right. Those naming conventions are old and that is why we have to
> improve those where ever and when ever required.
I'd love to see the "requirement" defined.
Regards,
Karsten
--
GPG key ID E4071346 @ eu.pool.sks-keyservers.net
E167 67FD A291 2BEA 73BD 4537 78B9 A9F9 E407 1346
--
Sent via pgsql-general mailing list (pgsql-general@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-general
All,
Please take note that when PG 9.2 was release, a column rename of
"procpid" to just "pid" in pg_stat_activity DID break prior user code,
therefore I must strongly advise against any other unnecessary column
renames in system catalogs.
--
Melvin Davidson
I reserve the right to fantasize. Whether or not you
wish to share my fantasy is entirely up to you.
I reserve the right to fantasize. Whether or not you
wish to share my fantasy is entirely up to you.
Sachin Kotwal wrote: > I believe these naming conventions will be at two levels: > > 1. Internal code of PostgreSQL , structures getting used internally > 2. SQL/C functions get executed at the time of database initialization to > create default objects and system catalogs. > > > I will see how much modifications/efforts need to be done and will come > back again if it is feasible. > > My intension is to improve naming conventions and increase naming string > where naming conventions are correct but make shorten. I think the proper amount of effort to rename existing system catalog columns is zero. Also, I think it's pretty difficult to change column names on views that have already been released. The compatibility break for existing tools is just too large. A valuable service would be to ensure that any new views, and new columns on existing views, have sensible names. -- Álvaro Herrera https://www.2ndQuadrant.com/ PostgreSQL Development, 24x7 Support, Remote DBA, Training & Services -- Sent via pgsql-general mailing list (pgsql-general@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-general
Hi,
--
Thanks and Regards,
It seems people worrying about failure of client side code after changes in column names.
Melvin also mention that just change in one column was broken many things.
>
> My intension is to improve naming conventions and increase naming string
> where naming conventions are correct but make shorten.
Sure. It make sense.
Definitely we can do this. Specially patch reviewers and committers need to take care of this. (I am not ordering to anyone here, just putting my thoughts)
I think the proper amount of effort to rename existing system catalog
columns is zero.
Can you clarify how efforts will be zero. Is there any script in place or automatic way of doing this?
Also, I think it's pretty difficult to change column names on views that
have already been released. The compatibility break for existing tools
is just too large.
It is correct. But then I think we can do below things:
1. Instead of pushing all changes at once , we can group them and push them slowly in each major version release.
2. We need to decide weather we really need those changes in old versions?
3. Notify or highlight these changes in release notes because this can break some existing tools and user code.
4. As Alvaro suggested, when developer working on any major code change, He should give proper naming conventions to system catalog/view column names in that area.
If It is impossible or not required to do this, then we can stop discussion with 4th point made by Alvaro as conclusion of this discussion.
Please committers give their final view on this.
Sachin Kotwal
Please committers give their final view on this.
They, and others, have - its a "don't want".
IOW, don't expend any effort since that effort will have been wasted - not that it would take zero effort to accomplish.
If there is an addition to the system catalogs overview page of the docs that describes the naming convention I think that would be swell.
David J.
Sachin Kotwal wrote:
> 3. Notify or highlight these changes in release notes because this can
> break some existing tools and user code.
Notifying people when their tools no longer work with a new server is
not the problem; they figure that out pretty quickly once they try the
new version. The problem is that if you change any names, the
application developers need to provide version-specific queries that
work across all the PG versions they want to support. That leads to
some pretty horrible code, annoyed developers, bad publicity for Pg
("you guys don't love your app developers!"), etc.
--
Álvaro Herrera https://www.2ndQuadrant.com/
PostgreSQL Development, 24x7 Support, Remote DBA, Training & Services
--
Sent via pgsql-general mailing list (pgsql-general@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-general
On Wed, Nov 8, 2017 at 12:41 AM, Alvaro Herrera <alvherre@alvh.no-ip.org> wrote:
> Sachin Kotwal wrote:
>> 3. Notify or highlight these changes in release notes because this can
>> break some existing tools and user code.
>
> Notifying people when their tools no longer work with a new server is
> not the problem; they figure that out pretty quickly once they try the
> new version. The problem is that if you change any names, the
> application developers need to provide version-specific queries that
> work across all the PG versions they want to support. That leads to
> some pretty horrible code, annoyed developers, bad publicity for Pg
> ("you guys don't love your app developers!"), etc.
This reminds me of pg_stat_activity whose pid column has been renamed,
and this column is widely used for monitoring... My experience on that
is that renaming induces technical debts, but applications would see
queries failing immediately, which is not complicated to grep and fix
properly as frontend code usually has already logic to track the
backend version number, and even if any deeper modification is needed
things like libpq allow to fetch the backend version easily. Column
name of function name changes happen (see xlog -> wal switch in v10),
and community is usually driven by consensus. So if there is a
proposal adopted by a majority of hackers thinking that changing a
column is worth long-term, then it could be considered for
integration. I personally tend to take with a pinch of salt such
proposals though if there are no good reasons behind a switch other
than because it-is-beautiful, so I agree with Álvaro that it is good
to be careful here.
--
Michael
--
Sent via pgsql-general mailing list (pgsql-general@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-general