On Tue, Feb 16, 2016 at 6:13 AM, Bruce Momjian <br...@momjian.us> wrote: > On Wed, Feb 10, 2016 at 04:39:15PM +0900, Kyotaro HORIGUCHI wrote: >> > I still agree with this plugin approach, but I felt it's still >> > complicated a bit, and I'm concerned that patch size has been >> > increased. >> > Please give me feedbacks. >> >> Yeah, I feel the same. What make it worse, the plugin mechanism >> will get further complex if we make it more flexible for possible >> usage as I proposed above. It is apparently too complicated for >> deciding whether to load *just one*, for now, converter >> function. And no additional converter is in sight. >> >> I incline to pull out all the plugin stuff of pg_upgrade. We are >> so prudent to make changes of file formats so this kind of events >> will happen with several-years intervals. The plugin mechanism >> would be valuable if we are encouraged to change file formats >> more frequently and freely by providing it, but such situation >> absolutely introduces more untoward things.. > > I agreed on ripping out the converter plugin ability of pg_upgrade. > Remember pg_upgrade was originally written by EnterpriseDB staff, and I > think they expected their closed-source fork of Postgres might need a > custom page converter someday, but it never needed one, and at this > point I think having the code in there is just making things more > complex. I see _no_ reason for community Postgres to use a plugin > converter because we are going to need that code for every upgrade from > pre-9.6 to 9.6+, so why not just hard-code in the functions we need. We > can remove it once 9.5 is end-of-life. >
Hm, we should rather remove the source code around PAGE_CONVERSION and page.c at 9.6? Regards, -- Masahiko Sawada -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers