Alvaro Herrera <alvhe...@commandprompt.com> writes:
> Tom Lane wrote:
>> I tend to think this isn't a very good idea. It's difficult for
>> applications to know whether a toast table will be created or not.
>> They should be able to just set the toast options and not worry.
> The problem is where do we store the options?
We don't. If there's no toast table, we don't need them after all.
Now the alternative position you could take is that if someone is
setting toast reloptions, they should darn well know the implementation
well enough to know whether the table will have a toast table or not.
In which case you should argue that this case ought to be an ERROR,
not a notice or warning. But I think that's probably unsustainably
anal. For example consider the following scenario:
create table foo (f1 int, f2 text);
set some toast reloptions on foo
alter table foo drop column f2;
pg_dump
At this point foo still has a toast table and presumably pg_dump will
dump its options. At reload, however, no toast table will be created,
and so throwing an error would be pretty embarrassing.
It's not hard to scale this up to find situations where the creation
of a toast table would be platform- or version-dependent (if the max
tuple width is just under a page).
If we are not able to teach pg_dump to predict whether the target
DB will create a toast table, we certainly can't expect applications
to know it. So I think setting toast reloptions on a table that has
no toast table should just be a silent no-op.
regards, tom lane
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
