Thread: Re: Retiring some encodings?
On Thu, May 22, 2025 at 02:44:39PM +0300, Heikki Linnakangas wrote: > On 22/05/2025 08:54, Michael Paquier wrote: > > With all that in mind, I have wanted to kick a discussion about > > potentially removing one or more encodings from the core code, > > including the backend part, the frontend part and the conversion > > routines, coupled with checks in pg_upgrade to complain with database > > or collations include the so-said encoding (the collation part needs > > to be checked when not using ICU). Just being able to removing > > GB18030 would do us a favor in the long-term, at least, but there's > > more. > > +1 at high level for deprecating and removing conversions that are not > widely used anymore. As the first step, we can at least add a warning to the > documentation, that they will be removed in the future. Agreed on notification. A radical idea would be to add a warning for the use of such encodings in PG 18, and then mention their deprecation in the PG 18 release notes so everyone is informed they will be removed in PG 19. -- Bruce Momjian <bruce@momjian.us> https://momjian.us EDB https://enterprisedb.com Do not let urgent matters crowd out time for investment in the future.
On 23/05/2025 05:11, Michael Paquier wrote: > On Thu, May 22, 2025 at 10:02:16AM -0400, Bruce Momjian wrote: >> Agreed on notification. A radical idea would be to add a warning for >> the use of such encodings in PG 18, and then mention their deprecation >> in the PG 18 release notes so everyone is informed they will be removed >> in PG 19. > > With v18beta1 already out in the wild, I think that we are too late > for taking any action on this version at this stage. Putting a > deprecation notice for a selected set of conversions and/or encodings > and do the actual removal work when v20 opens up around July 2026 > would sound like a better timing here, if the overall consensus goes > in this direction, of course. If we plan to remove something in the future, I think putting a deprecation notice in the docs in v18 is still a good idea. There's no point in hiding the plan by not documenting it sooner. The more advance notice people get the better. -- Heikki Linnakangas Neon (https://neon.tech)
> On 23 May 2025, at 09:18, Heikki Linnakangas <hlinnaka@iki.fi> wrote: > If we plan to remove something in the future, I think putting a deprecation notice in the docs in v18 is still a good idea.There's no point in hiding the plan by not documenting it sooner. The more advance notice people get the better. +1 -- Daniel Gustafsson
HI
> The obvious question is how many people would suffer because
> of that removal, as it would prevent them from using pg_upgrade.
> Can anybody who works in a region that uses these encodings make
> an educated guess?
> of that removal, as it would prevent them from using pg_upgrade.
> Can anybody who works in a region that uses these encodings make
> an educated guess?
+1 Agree ,GB18030 A coding standard in China, if deleted, will have an impact on the application of postgresql in China, and China is now experiencing more and more hot postgresql heat, need to consider carefully!
On Fri, May 23, 2025 at 4:22 PM Daniel Gustafsson <daniel@yesql.se> wrote:
> On 23 May 2025, at 09:18, Heikki Linnakangas <hlinnaka@iki.fi> wrote:
> If we plan to remove something in the future, I think putting a deprecation notice in the docs in v18 is still a good idea. There's no point in hiding the plan by not documenting it sooner. The more advance notice people get the better.
+1
--
Daniel Gustafsson