Re: ALTER TABLE ... NOREWRITE option

From: Andres Freund <andres(at)2ndquadrant(dot)com>
To: Josh Berkus <josh(at)agliodbs(dot)com>
Cc: pgsql-hackers(at)postgresql(dot)org
Subject: Re: ALTER TABLE ... NOREWRITE option
Date: 2012-12-01 20:32:20
Message-ID: 20121201203220.GB15334@awork2.anarazel.de
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

On 2012-12-01 12:24:57 -0800, Josh Berkus wrote:
>
> >> I'm not thrilled about inventing YA keyword for this. If you have a
> >> problem with that sort of scenario, why aren't you testing your DDL
> >> on a test server before you do it on production?
>
> *I* do test my DDL. However, there are literally hundreds of thousands
> of Rails, Django and Hibernate developers who "test" their DDL by
> running it using a 5-row dataset on their laptops before pushing it to
> production. As far as these folks are concerned, "rewrite if there's a
> default" is a completely unintuitive booby-trap.
>
> I agree that adding "NOREWRITE" is a bad solution, though. Personally,
> I'd rather have a system function which tests whether a series of DDL
> statements involves a rewrite anywhere. e.g.:
>
> SELECT pg_test_for_rewrite('ALTER TABLE josh ADD COLUMN haircolor')
>
> Hmmmm. Actually, that wouldn't work with migrations tools, especially
> Rails. Better, what about a GUC?
>
> SET message_on_rewrite=WARNING;

If you have a framework and you want to test for this you can just
compare relfilenodes before/after.

Greetings,

Andres Freund

--
Andres Freund http://www.2ndQuadrant.com/
PostgreSQL Development, 24x7 Support, Training & Services

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Josh Berkus 2012-12-01 20:35:15 Re: ALTER TABLE ... NOREWRITE option
Previous Message Josh Berkus 2012-12-01 20:24:57 Re: ALTER TABLE ... NOREWRITE option