Re: [PATCH][PROPOSAL] Refuse setting toast.* reloptions when TOAST table does not exist
От | Tom Lane |
---|---|
Тема | Re: [PATCH][PROPOSAL] Refuse setting toast.* reloptions when TOAST table does not exist |
Дата | |
Msg-id | 2802.1516318921@sss.pgh.pa.us обсуждение исходный текст |
Ответ на | Re: [PATCH][PROPOSAL] Refuse setting toast.* reloptions when TOASTtable does not exist (Robert Haas <robertmhaas@gmail.com>) |
Ответы |
Re: [PATCH][PROPOSAL] Refuse setting toast.* reloptions when TOAST table does not exist
Re: [PATCH][PROPOSAL] Refuse setting toast.* reloptions when TOASTtable does not exist |
Список | pgsql-hackers |
Robert Haas <robertmhaas@gmail.com> writes: > On Wed, Jan 17, 2018 at 3:50 PM, Nikolay Shaplov <dhyan@nataraj.su> wrote: >> This patch raises error if user tries o set or change toast.* option for a >> table that does not have a TOST relation. > I think there is a problem with this idea, which is that the rules for > whether or not a given table has an associated TOAST table > occasionally change from one major release to the next. Suppose that, > in release X, a particular table definition causes a TOAST table to be > created, but in release X+1, it does not. If a table with that > definition has a toast.* option set, then upgrading from release X to > release X+1 via pg_dump and restore will fail. That's bad. Yeah --- and it doesn't even have to be a major version change; the same version on different hardware might make different choices too. Not to mention that there is discussion out there about making the toasting rules more configurable. There might be a case for raising a warning in this situation, but I would disagree with making it a hard error in any case. All that's going to accomplish is to break people's scripts and get them mad at you. regards, tom lane
В списке pgsql-hackers по дате отправления: