Re: [HACKERS] [PATCH] Rename pg_switch_xlog to pg_switch_wal
От | Robert Haas |
---|---|
Тема | Re: [HACKERS] [PATCH] Rename pg_switch_xlog to pg_switch_wal |
Дата | |
Msg-id | CA+TgmoZdSgPaUzbLLfbQQqW3U8NzY__WV80Ch=ed1CCNhS4MQg@mail.gmail.com обсуждение исходный текст |
Ответ на | Re: [HACKERS] [PATCH] Rename pg_switch_xlog to pg_switch_wal (David Steele <david@pgmasters.net>) |
Список | pgsql-hackers |
On Thu, Jan 12, 2017 at 8:56 AM, David Steele <david@pgmasters.net> wrote: >> So, to sum up things on this thread, here are the votes about the use >> of aliases or a pure breakage: >> - No to aliases, shake the world: Stephen, Tom, David F, Vik, Bruce M => 5 >> - Yes to aliases: Michael P, Andres, Peter E., Cynthia S, Jim N, >> Vladimir, Simon R, Fujii-san => 8 >> If I misunderstood things, please feel free to speak up. > > I'm also in the "no to aliases" camp. Me too. I appreciate what people are saying about the pain that is involved when we change administration interfaces. However, I suspect that most of that pain falls on tool authors, who are disproportionately represented in this forum, and on DBAs, who may not like it much but can probably cope with it. It's not really going to affect applications, because applications generally don't care about the transaction log directly. What is really bad is when we break syntax that might be used in queries, or in PL/pgsql functions. That's why the 8.3 casting changes were so painful, and why the discussion about changing PL/pgsql semantics is so dominated by people who don't want to break what's worth now. When we change things in those areas, people who know nothing and care nothing about PostgreSQL other than that it's the underlying database have to update their SQL, and that hurts adoption. Anyone who is affected by these proposed changes is already deeply invested in PostgreSQL. Also, I think it is absolutely wrong to suppose that there's no pain involved in having these aliases around forever. I thought the idea of stuffing the aliases in a contrib module was a rather good one, actually, because then the people who need them can install them easily and yet the burden on core to maintain them is largely removed. Also, there's still positive pressure for tools that haven't been updated to get themselves updated to work without that compatibility extension, so eventually the need for it should go away. I have not abandoned all hope of eventually removing contrib/tsearch2 from the core distribution. When we keep things in the core system catalogs, they just accumulate forever. There will not only be old code that continues to use the old names; there will be new code that uses the old names. There will be people who ask why we have two copies of the function, or aren't sure which one to use. Somebody will have a tab-completion fail that results from an irrelevant decision between two names for the same thing. Individually, these things don't matter very much, but over time they lead to a user experience that's full of warts and a developer experience that is enslaved to historical garbage that takes time and energy away from new feature development. So, my order of preference is: 1. Rename everything and add an extension to create aliases for the old names. 2. Rename everything without adding a backward-compatibility extension. 3. Don't rename anything. 4. Stomach flu. 5. Put a second name for everything in pg_proc.h. -- Robert Haas EnterpriseDB: http://www.enterprisedb.com The Enterprise PostgreSQL Company
В списке pgsql-hackers по дате отправления:
Предыдущее
От: Tom LaneДата:
Сообщение: Re: [HACKERS] BUG: pg_stat_statements query normalization issues with combined queries