From: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
---|---|
To: | "Christopher Kings-Lynne" <chriskl(at)familyhealth(dot)com(dot)au> |
Cc: | pgsql-hackers(at)postgresql(dot)org |
Subject: | Re: Help with ADD COLUMN |
Date: | 2002-11-24 21:16:46 |
Message-ID: | 3488.1038172606@sss.pgh.pa.us |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
"Christopher Kings-Lynne" <chriskl(at)familyhealth(dot)com(dot)au> writes:
>> Basically you wanna do an "UPDATE tab SET col = <default expr>". I'd
>> suggest letting the existing machinery handle as much of that as
>> possible.
> Using SPI calls?
I wouldn't use SPI; it introduces way too many variables --- besides
which, you already have the default in internal form, why would you want
to deparse and reparse it?
I'd look into building a parsetree for an UPDATE statement and
feeding that to the executor.
An interesting question: should the rewriter be allowed to get its hands
on the thing, or not? I'm not sure it'd be a good idea to fire rules
for such an operation. For that matter, perhaps we don't want to fire
triggers either --- just how close should this come to being like a regular
UPDATE?
It would probably net out to not a lot of code to do a heapscan,
heap_modify_tuple, etc if we decide that not firing rules/triggers
is more appropriate behavior. I'm not sure.
regards, tom lane
From | Date | Subject | |
---|---|---|---|
Next Message | Tom Lane | 2002-11-24 21:56:09 | Re: Using the same condition twice |
Previous Message | Christopher Kings-Lynne | 2002-11-24 20:35:46 | Re: Help with ADD COLUMN |