Re: [PATCH][PROPOSAL] Refuse setting toast.* reloptions when TOAST table does not exist

From: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
To: Robert Haas <robertmhaas(at)gmail(dot)com>
Cc: Nikolay Shaplov <dhyan(at)nataraj(dot)su>, "pgsql-hackers(at)postgresql(dot)org" <pgsql-hackers(at)postgresql(dot)org>, Alvaro Herrera <alvherre(at)2ndquadrant(dot)com>
Subject: Re: [PATCH][PROPOSAL] Refuse setting toast.* reloptions when TOAST table does not exist
Date: 2018-01-18 23:42:01
Message-ID: 2802.1516318921@sss.pgh.pa.us
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

Robert Haas <robertmhaas(at)gmail(dot)com> writes:
> On Wed, Jan 17, 2018 at 3:50 PM, Nikolay Shaplov <dhyan(at)nataraj(dot)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

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Ashwin Agrawal 2018-01-18 23:58:31 make_etags: avoid recursive symbolic creation.
Previous Message Tom Lane 2018-01-18 23:35:41 Re: [HACKERS] Refactor handling of database attributes between pg_dump and pg_dumpall