Tom Lane wrote: > 2. There seem to be some corner cases where creating a table in the new > database will not create a toast table even though there was one in the > previous instance. (I'm not 100% convinced that this can happen if we > create and then drop dropped columns, for instance ... but I'm not > convinced it can't happen, either.) If there is a toast table in the > old database then pg_migrator must bring it over because it might > possibly contain live data. However, as toasting.c is presently coded > there is no way to force it to create a toast table. I think we should > change AlterTableCreateToastTable to add a "bool force" parameter. > Alternatively we could add a separate entry point, but the option seems > a bit cleaner.
The bottom line is that the TOAST logic was so fluid on when it thinks a TOAST table is needed that even if it it consistent from 8.3 -> 8.4, it would likely break in some later release and it was just safer to add a boolean. -- Bruce Momjian <br...@momjian.us> http://momjian.us EnterpriseDB http://enterprisedb.com + If your life is a hard drive, Christ can be your backup. + -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
