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
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
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
could
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't mean to
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 Eisentraut
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
time)
-
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 column IS NULL
The where clause would avoid issues with inherited data being
overwritten when
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 new
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 answer to
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
updated? Are
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
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.
When
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 least
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 regards to
14 matches
Mail list logo