On Tue, Jan 11, 2011 at 7:25 AM, Noah Misch <n...@leadboat.com> wrote: > On Tue, Jan 11, 2011 at 06:37:33AM -0500, Robert Haas wrote: >> On Sun, Jan 9, 2011 at 4:59 PM, Noah Misch <n...@leadboat.com> wrote: >> > This begins the patch series for the design I recently proposed[1] for >> > avoiding >> > some table rewrites in ALTER TABLE ... ALTER COLUMN ... TYPE. ?I'm posting >> > these >> > patches today: >> > >> > 0 - new test cases >> >> This doesn't look right. You might be building it, but you sure >> aren't rebuilding it. >> >> +CREATE TABLE parent (keycol numeric PRIMARY KEY); >> +NOTICE: CREATE TABLE / PRIMARY KEY will create implicit index >> "parent_pkey" for table "parent" >> +DEBUG: Rebuilding index "parent_pkey" > > Yes. I considered saying "Building" unconditionally. Differentiating the > debug > message by passing down the fact that the index recently existed seemed like > overkill. What do you think?
I'm wondering if we should consider moving this call to index_build() so that it appears everywhere that we build an index rather than just in ALTER TABLE, and saying something like: building index "%s" on table "%s" > The theoretical basis is that users can do little to directly change the need > to > rebuild a TOAST index. We'll rebuild the TOAST index if and only if we > rewrote > the table. The practical basis is that the TOAST relation names contain > parent > relation OIDs, so we don't want them mentioned in regression test output. Perhaps in this case we could write: building TOAST index for table "%s" There's limited need for users to know the actual name of the TOAST table, but I think it's better to log a line for all the actions we're performing or none of them, rather than some but not others. -- Robert Haas EnterpriseDB: http://www.enterprisedb.com The Enterprise PostgreSQL Company -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers