В письме от 18 января 2018 18:42:01 пользователь Tom Lane написал:
> >> 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.
These all sound very reasonable, but still does not solve problem with loosing
toast option values when you set one for table without TOAST relation.
May be, if reasons for existence TOAST relation is no so much fixed thing (I
thought it is almost as fixed as a rock), may be the solution would be to
create a TOAST relation anyway if toast options is set, and gave a warning
that may be setting this option is not the thing the user really want?
This way we will not loose option values. And it would be 100% backward
compatible.
The main misfeature here is that we will have empty TOAST relation in this
case. But first I do not think it will really harm anybody, and second, we
would WARN that it is not the best way to do things, so DB user will be able
to find way around.
What do you think about it?
--
Do code for fun.
