From: | Noah Misch <noah(at)leadboat(dot)com> |
---|---|
To: | Robert Haas <robertmhaas(at)gmail(dot)com> |
Cc: | pgsql-hackers(at)postgresql(dot)org |
Subject: | Re: ALTER TYPE 2: skip already-provable no-work rewrites |
Date: | 2011-02-13 11:50:07 |
Message-ID: | 20110213115007.GA21248@tornado.leadboat.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
On Sun, Feb 13, 2011 at 12:04:20AM -0500, Robert Haas wrote:
> On Sat, Feb 12, 2011 at 10:45 AM, Noah Misch <noah(at)leadboat(dot)com> wrote:
> > That said, I've tried both constructions, and I marginally prefer the end result
> > with AlteredTableInfo.verify. ?I've inlined ATColumnChangeRequiresRewrite into
> > ATPrepAlterColumnType; it would need to either pass back two bools or take an
> > AlteredTableInfo arg to mutate, so this seemed cleaner.
>
> I think I like the idea of passing it the AlteredTableInfo.
Okay.
> > I've omitted the
> > assertion that my previous version added to ATRewriteTable; it was helpful for
> > other scan-only type changes, but it's excessive for domains alone. ?Otherwise,
> > the differences are cosmetic.
>
> So in the case of a constrained domain, it looks like we're going to
> evaluate the changed columns, but if no error is thrown, we're going
> to assume they match the original ones and throw out the data?
Correct. We can see that a RelabelType changes no values by inspecting
ExecEvalRelabelType. Likewise, by inspecting ExecEvalCoerceToDomain, we can
know that a CoerceToDomain node may introduce errors but never modified values.
> Yikes.
> I didn't like that Assert much, but maybe we need it, because this is
> scary.
Can you elaborate on the fear-inducing aspect? I don't mind re-adding the
Assert, but it seems that some positive understanding of the assumption's
validity is in order.
nm
From | Date | Subject | |
---|---|---|---|
Next Message | Dimitri Fontaine | 2011-02-13 11:56:03 | Re: Debian readline/libedit breakage |
Previous Message | Magnus Hagander | 2011-02-13 11:33:06 | Re: Debian readline/libedit breakage |