On Wed, Jan 17, 2018 at 3:50 PM, Nikolay Shaplov <dh...@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
