Skip site navigation (1) Skip section navigation (2)

Re: Eliminating phase 3 requirement for varlen increases via ALTER COLUMN

From: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
To: "Jonah H(dot) Harris" <jonah(dot)harris(at)gmail(dot)com>
Cc: pgsql-hackers(at)postgresql(dot)org, pgsql-patches(at)postgresql(dot)org
Subject: Re: Eliminating phase 3 requirement for varlen increases via ALTER COLUMN
Date: 2006-10-26 20:00:49
Message-ID: 24618.1161892849@sss.pgh.pa.us (view raw or flat)
Thread:
Lists: pgsql-hackerspgsql-patches
"Jonah H. Harris" <jonah(dot)harris(at)gmail(dot)com> writes:
> On 10/26/06, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> wrote:
>> This makes some really quite unacceptable assumptions about
>> the meaning and encoding of typmod ...

> True, so VARCHAR seems like the only one?  That's the only one I've
> really encountered in the field on a fairly regular basis.

Well, you could either hardwire some specific cases for specific types
here, or think about inventing a general-purpose mechanism that would
let types register a function to report whether a given typmod change
requires actual work.  I'm not sure it's worth the latter though.

One point worth thinking about is that varchar(any) --> text could be
a "free" coercion too, along with cases such as replacing a domain
by its base type.  I think we can detect this today by the
expedient of noting whether the coercion ends up being just a
RelabelType expression --- I'm actually a bit surprised that that
knowledge doesn't seem to be in the code already.

OTOH ... RelabelType means the bits are the same but it doesn't imply
that the semantics of the bits are the same, eg, OID has a different
sort order than int4.  So ISTM that in general it'd still be necessary
to recheck constraints and rebuild indexes.  This might be a sufficient
reason for limiting the optimization to a few known-safe cases like
varchar/text, rather than trying to do it for any binary-compatible
conversion.

Another thought is that some cases would amount to checking constraints
but not changing any bits on-disk, as in replacing a base type with a
domain.  Is it worth having these go through the non-rewriting code
path?  How would we be sure we didn't need to rebuild indexes?

			regards, tom lane

In response to

pgsql-hackers by date

Next:From: Stefan KaltenbrunnerDate: 2006-10-26 20:09:56
Subject: Re: plperl/plperlu interaction
Previous:From: Andrew DunstanDate: 2006-10-26 19:58:40
Subject: Re: plperl/plperlu interaction

pgsql-patches by date

Next:From: Gregory StarkDate: 2006-10-26 20:40:27
Subject: Re: [HACKERS] Eliminating phase 3 requirement for varlen increases via ALTER COLUMN
Previous:From: Jonah H. HarrisDate: 2006-10-26 19:48:54
Subject: Re: Eliminating phase 3 requirement for varlen increases via ALTER COLUMN

Privacy Policy | About PostgreSQL
Copyright © 1996-2014 The PostgreSQL Global Development Group