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 believe it is the only right thing to do, as now if you set toast reloption
> for table that does not have TOAST table, the value of this option will be
> lost without any warning. You will not get it back with pg_dump, it will not
> be effective when you add varlen attributes to the table later.
>
> So you offer DB some value to store, it accepts it without errors, and
> immediately loses it. I would consider it a bad behavior.
>
> I also think that we should not change this error to warning, as toast.*
> options are usually used by very experienced users for precised DB tunning. I
> hardly expect them to do TOAST tuning for tables without TOAST relations. So
> chances to get problem with existing SQL code are minimal.
>
> So I would suggest to throw an error in this case.
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.
--
Robert Haas
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company
