Re: Do we really need to switch to per-tuple memory context in ATRewriteTable() when Table Rewrite is not happening

>>>>> "Ashutosh" == Ashutosh Sharma <ashu.coek88@gmail.com> writes:

 Ashutosh> Hi All,

 Ashutosh> Today while trying to understand the code for ALTER TABLE in
 Ashutosh> PostgreSQL (basically the table rewrite part), I noticed that
 Ashutosh> we are switching to a per-tuple memory context even when
 Ashutosh> table rewrite is not required. For e.g.. consider the case
 Ashutosh> where we do ADD CONSTRAINTS (NOT NULL or CHECK) using ALTER
 Ashutosh> TABLE command. In this case, we just scan the tuple and
 Ashutosh> verify it for the given constraint instead of forming a new
 Ashutosh> tuple. So, not sure why do we switch to per-tuple memory
 Ashutosh> context when just adding the constraint.

What makes you think that evaluating the constraint won't allocate
memory?

Switching contexts is virtually free (just an assignment to a global
var). Resetting a context that's not been allocated in since its last
reset is also virtually free (just checks a flag). In contrast, every
single function (except special cases like index comparators) is free to
allocate memory in its caller's context, for temporary use and for
returning the result; how else would a condition like
CHECK(substring(col for 3)='FOO') work, without allocating memory for
the substring result?

-- 
Andrew (irc:RhodiumToad)