Re: Which SET TYPE don't actually require a rewrite

From: Noah Misch <noah(at)leadboat(dot)com>
To: Magnus Hagander <magnus(at)hagander(dot)net>
Cc: PostgreSQL Developers <pgsql-hackers(at)lists(dot)postgresql(dot)org>
Subject: Re: Which SET TYPE don't actually require a rewrite
Date: 2020-07-17 03:40:13
Message-ID: 20200717034013.GA452830@rfd.leadboat.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

On Wed, Jul 15, 2020 at 02:54:37PM +0200, Magnus Hagander wrote:
> Our Fine Manual (TM) specifies:
> "As an exception, when changing the type of an existing column, if the
> USING clause does not change the column contents and the old type is either
> binary coercible to the new type or an unconstrained domain over the new
> type, a table rewrite is not needed; but any indexes on the affected
> columns must still be rebuilt."
>
> First of all, how is a non-internals-expert even supposed to know what a
> binary coercible type is?

The manual defines it at <firstterm>binary coercible</firstterm>.

> We can also for example increase the precision of numeric without a rewrite
> (but not scale). Or we can change between text and varchar. And we can
> increase the length of a varchar but not decrease it.
>
> Surely we can do better than this when it comes to documenting it? Even if
> it's a pluggable thing so it may or may not be true of external
> datatypes installed later, we should be able to at least be more clear
> about the builtin types, I think?

I recall reasoning that ATColumnChangeRequiresRewrite() is a DDL analog of
query optimizer logic. The manual brings up only a minority of planner
optimizations, and comprehensive lists of optimization preconditions are even
rarer. But I don't mind if $SUBJECT documentation departs from that norm.

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Andrey V. Lepikhov 2020-07-17 04:23:19 Re: Partitioning and postgres_fdw optimisations for multi-tenancy
Previous Message Thomas Munro 2020-07-17 03:34:50 Re: Does TupleQueueReaderNext() really need to copy its result?