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

>>>>> "Ashutosh" == Ashutosh Sharma <ashu(dot)coek88(at)gmail(dot)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)