> Thats still double the disk space, although that has the nice side
> effect of not requiring a vacuum.
Also, a rollback after 99% of the updates have been done will waste no
diskspace...
Chris
---(end of broadcast)---
TIP 4: Don't 'kill -9' the
On Thu, 2003-06-19 at 21:22, Christopher Kings-Lynne wrote:
> > There is no alternative, unless you want the command to be
> > non-roll-back-able.
>
> Well, you can do a cluster-type table duplication...
Thats still double the disk space, although that has the nice side
effect of not requiring a
> There is no alternative, unless you want the command to be
> non-roll-back-able.
Well, you can do a cluster-type table duplication...
> > Someone can
> > make it more efficient in regards to constraint checks, etc. in the
> > future if they want -- I don't intend to.
>
> It'd be nice if you at
On Thu, 2003-06-19 at 15:00, Tom Lane wrote:
> Rod Taylor <[EMAIL PROTECTED]> writes:
> > Right now if the column exists in the child table, the add column is
> > rejected. I assume that will remain.
>
> Have you actually tried it?
I used different datatypes which, of course, was the wrong test.
Rod Taylor <[EMAIL PROTECTED]> writes:
> Right now if the column exists in the child table, the add column is
> rejected. I assume that will remain.
Have you actually tried it?
regression=# create table p1 (f1 int);
CREATE TABLE
regression=# create table c1 (f2 int) inherits(p1);
CREATE TABLE
re
On Thu, 2003-06-19 at 10:42, Tom Lane wrote:
> Rod Taylor <[EMAIL PROTECTED]> writes:
> > On Thu, 2003-06-19 at 10:05, Alvaro Herrera wrote:
> >> Sorry, I haven't read the spec, but what happens when there is a default
> >> value already and it's not NULL? Are tuples where column =3D default
> >>
Rod Taylor <[EMAIL PROTECTED]> writes:
> On Thu, 2003-06-19 at 10:05, Alvaro Herrera wrote:
>> Sorry, I haven't read the spec, but what happens when there is a default
>> value already and it's not NULL? Are tuples where column =3D default
>> updated? Are tuples where column IS NULL updated?
> W
> > Anyway, I suppose you have indirectly confirmed that user triggers, etc.
> > should NOT fire on for the data update. I didn't see anything in the
> > spec that said one way or the other.
>
> The spec doesn't say that they fire, so that means that they don't fire.
Sounds like a definitive ans
On Thu, 2003-06-19 at 10:05, Alvaro Herrera wrote:
> On Thu, Jun 19, 2003 at 09:52:14AM -0400, Rod Taylor wrote:
> > On Thu, 2003-06-19 at 09:40, Tom Lane wrote:
>
> > Do we want them to? If we don't mind them being executed, it is far
> > easier to:
> >
> > - alter table structure
> > - Add all
Rod Taylor <[EMAIL PROTECTED]> writes:
> - alter table structure
> - Add all new constraints (without confirming their correctness at that
> time)
> - update table contents via an SPI call to UPDATE WHERE IS NULL
> The where clause would avoid issues with inherited data being
> overwritten when t
On Thu, Jun 19, 2003 at 09:52:14AM -0400, Rod Taylor wrote:
> On Thu, 2003-06-19 at 09:40, Tom Lane wrote:
> Do we want them to? If we don't mind them being executed, it is far
> easier to:
>
> - alter table structure
> - Add all new constraints (without confirming their correctness at that
> ti
Rod Taylor writes:
> Anyway, I suppose you have indirectly confirmed that user triggers, etc.
> should NOT fire on for the data update. I didn't see anything in the
> spec that said one way or the other.
The spec doesn't say that they fire, so that means that they don't fire.
--
Peter Eisentra
On Thu, 2003-06-19 at 09:40, Tom Lane wrote:
> Rod Taylor <[EMAIL PROTECTED]> writes:
> > Anyway, I suppose you have indirectly confirmed that user triggers, etc.
> > should NOT fire on for the data update. I didn't see anything in the
> > spec that said one way or the other.
>
> Actually, I didn
Rod Taylor <[EMAIL PROTECTED]> writes:
> Anyway, I suppose you have indirectly confirmed that user triggers, etc.
> should NOT fire on for the data update. I didn't see anything in the
> spec that said one way or the other.
Actually, I didn't mean to take a position one way or the other. You
cou
> > Someone can
> > make it more efficient in regards to constraint checks, etc. in the
> > future if they want -- I don't intend to.
>
> It'd be nice if you at least ensure that all the constraints are checked
> in a single pass over the table (not one per constraint). Right offhand
> I do not s
Rod Taylor <[EMAIL PROTECTED]> writes:
> For the update I intend to use double space, as if the user did those
> items as individual commands within the same transaction.
There is no alternative, unless you want the command to be
non-roll-back-able.
> Someone can
> make it more efficient in regar
I took a quick glance at this.
It boils down to essentially an:
1) ALTER TABLE .. ADD COLUMN DEFAULT
2) UPDATE .. SET = IF IS NOT NULL;
3) Add including NOT NULL, CHECK, Foreign Key, etc. each
of which will do it's own confirmation pass on the values inserted into
the table by step 2 for t
17 matches
Mail list logo
