From: | Simon Riggs <simon(at)2ndQuadrant(dot)com> |
---|---|
To: | Noah Misch <noah(at)leadboat(dot)com> |
Cc: | pgsql-hackers(at)postgresql(dot)org |
Subject: | Re: ALTER TYPE 0: Introduction; test cases |
Date: | 2011-01-11 12:37:28 |
Message-ID: | 1294749448.12610.6301.camel@ebony |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
On Tue, 2011-01-11 at 07:14 -0500, Noah Misch wrote:
> These changes do make it harder to guess how much work the ALTER TABLE
> will do. Indeed, about 1/4 of my own guesses prior to writing were
> wrong. Something like WITHOUT REWRITE might be the way to go, though
> there are more questions: if it does not rewrite, does it scan the
> table? Which indexes, if any, does it rebuild? Which foreign key
> constraints, if any, does it recheck? With patch 0, you can answer
> all these questions by enabling DEBUG1 messages and trying the command
> on your test system. For this reason, I did consider adding a VERBOSE
> clause to show those messages at DETAIL, rather than unconditionally
> showing them at DEBUG1. In any case, if a WITHOUT REWRITE like you
> describe covers the important question, it's certainly easy enough to
> implement.
Trouble is, only superusers can set DEBUG1.
You're right, its more complex than I made out, though that strengthens
the feeling that we need a way to check what it does before it does it,
or a way to limit your expectations. Ideally that would be a
programmatic way, so that pgAdmin et al can issue a warning.
Given your thoughts above, my preference would be for
EXPLAIN ALTER TABLE to describe the actions that will take place.
Or other ideas...
--
Simon Riggs http://www.2ndQuadrant.com/books/
PostgreSQL Development, 24x7 Support, Training and Services
From | Date | Subject | |
---|---|---|---|
Next Message | Dan Langille | 2011-01-11 12:45:18 | PGCon 2011 Call for Papers - reminder |
Previous Message | Csaba Nagy | 2011-01-11 12:37:15 | Re: ALTER TYPE 0: Introduction; test cases |