On Thu, Nov 24, 2005 at 11:11:34AM -0500, Jan Wieck wrote:
On 11/24/2005 1:30 AM, Martijn van Oosterhout wrote:
Umm, if there are any errors you abort the transaction, just like any
other case. ACID requires that either the whole statement is done, or
none. If a trigger causes the INSERT or
On 11/25/2005 7:14 AM, Martijn van Oosterhout wrote:
On Thu, Nov 24, 2005 at 11:11:34AM -0500, Jan Wieck wrote:
I guess you misunderstood. [...]
But I'm not sure we're supposed to handle that case anyway. Oracle at
least doesn't require an index on the table being merged. And if I look
at it
On Fri, Nov 25, 2005 at 09:14:47AM -0500, Jan Wieck wrote:
Hmmm ... so you maintain that MERGE without an explicit LOCK TABLE, done
by the user before performing the MERGE, can create duplicate rows (WRT
the merge condition) and consequently raise a duplicate key error if
there is a UNIQUE
On 11/24/2005 1:30 AM, Martijn van Oosterhout wrote:
On Wed, Nov 23, 2005 at 04:55:25PM -0500, Jan Wieck wrote:
The largest problem I see with MERGE is the question of BEFORE triggers.
Consider a BEFORE INSERT trigger that modifies a third table, after
which the constraint or whatever
On 11/11/2005 2:20 PM, Tom Lane wrote:
Peter Eisentraut [EMAIL PROTECTED] writes:
Tom Lane wrote:
Surely they require a unique constraint --- else the behavior isn't
even well defined, is it?
They require that the merge condition does not match for more than one
row, but since the merge
On Wed, Nov 23, 2005 at 04:55:25PM -0500, Jan Wieck wrote:
The largest problem I see with MERGE is the question of BEFORE triggers.
Consider a BEFORE INSERT trigger that modifies a third table, after
which the constraint or whatever post-heap_insert-attempt we might use
detects a conflict.
On Fri, Nov 18, 2005 at 09:03:25PM +0100, Martijn van Oosterhout wrote:
I'd say implement SQL MERGE which doesn't have any really unusual
features. And seperately implement some kind of INSERT OR UPDATE which
works only for a table with a primary key.
Is there any reeason this has to be a PK;
Bruce Momjian wrote:
I agree --- an implementation that needs to use a table lock is
useless, and one with no primary key is too hard to implement and
also near useless.
Well, there were just a couple of people saying the opposite.
I have update the TODO item to reflect this:
* Add
On Fri, Nov 18, 2005 at 05:30:34PM +0100, Peter Eisentraut wrote:
Bruce Momjian wrote:
I have update the TODO item to reflect this:
* Add MERGE command that does UPDATE/DELETE, or on failure, INSERT
(rules, triggers?)
To implement this cleanly requires that the table
Peter Eisentraut wrote:
Bruce Momjian wrote:
I agree --- an implementation that needs to use a table lock is
useless, and one with no primary key is too hard to implement and
also near useless.
Well, there were just a couple of people saying the opposite.
I have update the TODO item
Csaba Nagy wrote:
session_1= create table test (col smallint primary key);
NOTICE: CREATE TABLE / PRIMARY KEY will create implicit index
test_pkey for table test
CREATE TABLE
session_1= begin;
BEGIN
cnagy= insert into test values (1);
INSERT 165068987 1
session_2= begin;
BEGIN
Well, from my point of view it is a special case of predicate locking
supported well by existing code, in this case the unique index (you said
that, I'm not familiar with the code). I don't see why this cannot be
capitalized on, to implement a sub-set of what predicate locking is,
based on the
On 11/15/05, Alvaro Herrera [EMAIL PROTECTED] wrote:
Csaba Nagy wrote:
session_1= create table test (col smallint primary key);
NOTICE: CREATE TABLE / PRIMARY KEY will create implicit index
test_pkey for table test
CREATE TABLE
session_1= begin;
BEGIN
cnagy= insert into test
Alvaro Herrera [EMAIL PROTECTED] writes:
This only happens because of the unique index. There's no predicate
locking involved. The btree code goes some lengths to make this work;
That's one way to look at it; the other is to say that we have predicate
locking for a very specific class of
Tom Lane wrote:
Alvaro Herrera [EMAIL PROTECTED] writes:
This only happens because of the unique index. There's no predicate
locking involved. The btree code goes some lengths to make this work;
That's one way to look at it; the other is to say that we have predicate
locking for a very
On Fri, 2005-11-11 at 20:22, Bruno Wolff III wrote:
On Fri, Nov 11, 2005 at 18:48:33 +0100,
Csaba Nagy [EMAIL PROTECTED] wrote:
OK, I'm relatively new on this list, and I might have missed a few
discussions on this topic.
I wonder if doing it this way would not be better than using a
Jaime,
so i suppose we can reuse many of the code breaking the merge in 3
pieces... for now they are just thougths, i will think more in this
and try to implement it...
comments? ideas? suggestions?
Funny, we were just discussing this at OpenDBCon. Seems that you can't do a
full
On 11/11/05, Josh Berkus josh@agliodbs.com wrote:
Jaime,
so i suppose we can reuse many of the code breaking the merge in 3
pieces... for now they are just thougths, i will think more in this
and try to implement it...
comments? ideas? suggestions?
Funny, we were just discussing this
Jaime Casanova wrote:
Funny, we were just discussing this at OpenDBCon. Seems that you can't do a
full implementation of MERGE without Predicate Locking (the ability to say
lock this table against inserts or updates of any row with key=5).
it isn't what select for update does?
On Fri, 2005-11-11 at 18:15, Jaime Casanova wrote:
On 11/11/05, Josh Berkus josh@agliodbs.com wrote:
Jaime,
so i suppose we can reuse many of the code breaking the merge in 3
pieces... for now they are just thougths, i will think more in this
and try to implement it...
Josh Berkus wrote:
Funny, we were just discussing this at OpenDBCon. Seems that you
can't do a full implementation of MERGE without Predicate Locking
(the ability to say lock this table against inserts or updates of
any row with key=5). However, Peter suggested that we could do a
Josh Berkus josh@agliodbs.com writes:
Funny, we were just discussing this at OpenDBCon. Seems that you can't do a
full implementation of MERGE without Predicate Locking (the ability to say
lock this table against inserts or updates of any row with key=5).
However, Peter suggested that we
OK, I'm relatively new on this list, and I might have missed a few
discussions on this topic.
I wonder if doing it this way would not be better than using a table
lock:
- set a save point;
- insert the row;
- on error:
- roll back to the save point;
- update the row;
-
Tom Lane wrote:
If you don't have any better idea how to do it than a full table
lock, you might as well not do it at all. A proof of concept that
doesn't solve the hard part of the problem is no proof :-(
But the problem here is not to break any kind of performance barrier,
but to give
Peter Eisentraut [EMAIL PROTECTED] writes:
This assumes that there are indexes defined for the columns involved in
the merge condition, which is not required anywhere.
Surely they require a unique constraint --- else the behavior isn't even
well defined, is it?
On 11/11/05, Peter Eisentraut [EMAIL PROTECTED] wrote:
Tom Lane wrote:
If you don't have any better idea how to do it than a full table
lock, you might as well not do it at all. A proof of concept that
doesn't solve the hard part of the problem is no proof :-(
But the problem here is not
Tom Lane wrote:
Surely they require a unique constraint --- else the behavior isn't
even well defined, is it?
They require that the merge condition does not match for more than one
row, but since the merge condition can do just about anything, there is
no guarantee that a unique constraint
Jaime Casanova Wrote:
But MERGE isn't REPLACE...
REPLACE will delete old records to insert new ones; MERGE try
to insert and if the record exists then can UPDATE just a few
values, maybe incrementing them with a value (all the
calculation are doing by the MERGE)
That sounds like
Jaime Casanova wrote:
REPLACE will delete old records to insert new ones; MERGE try to
insert and if the record exists then can UPDATE just a few values,
maybe incrementing them with a value (all the calculation are doing
by the MERGE)
I'm not the expert on REPLACE, but it would seem that
On Fri, Nov 11, 2005 at 18:48:33 +0100,
Csaba Nagy [EMAIL PROTECTED] wrote:
OK, I'm relatively new on this list, and I might have missed a few
discussions on this topic.
I wonder if doing it this way would not be better than using a table
lock:
- set a save point;
- insert the row;
Peter Eisentraut [EMAIL PROTECTED] writes:
Tom Lane wrote:
Surely they require a unique constraint --- else the behavior isn't
even well defined, is it?
They require that the merge condition does not match for more than one
row, but since the merge condition can do just about anything,
I Wrote:
From the mysql manual:
'REPLACE works exactly like INSERT, except that if an old
record in the table has the same value as a new record for a
PRIMARY KEY or a UNIQUE index, the old record is deleted
before the new record is inserted. See Section 13.2.4,
INSERT Syntax.'
It
Tom Lane Wrote:
Surely they require a unique constraint --- else the behavior
isn't even well defined, is it?
From the mysql manual:
'REPLACE works exactly like INSERT, except that if an old record in the
table has the same value as a new record for a PRIMARY KEY or a UNIQUE
index, the old
33 matches
Mail list logo
