Richard Ellis <[EMAIL PROTECTED]> writes:
> True, if the row does not already exist. But in that situation,
> because of the unique constraint premise in the original quote, there
> is always going to be at least one failed transaction. So the battle
> is already lost before it's even begun.
W
Whatever you guy's try or suggest, it's doomed to suffer.
The whole problem stems from using a non-standard feature. And in my
opinion MySQL's "REPLACE INTO" is less a feature or extension to the
standard than more another stupid and lesser thought through addition of
apparently speed gaining c
On Thu, Sep 04, 2003 at 12:29:17PM -0700, Stephan Szabo wrote:
>
> On Thu, 4 Sep 2003, Richard Ellis wrote:
>
> > On Thu, Sep 04, 2003 at 12:17:35PM +0200, Csaba Nagy wrote:
> > > [philosophical post regarding a missing feature of Postgres]
> > >
> > > I found there's no way to avoid failed inser
However, that doesn't cover the case where you want to update the record
if it already exists.
Jon
> insert into test (a, b, c, d)
> (select 1, 2, 3, 4 where not exists
> (select 1 from test where a=1 and b=2 and c=3 and d=4)
> );
>
> If your table contains a=1, b=2, c=3, and d=4, nothing
On Thu, 4 Sep 2003, Richard Ellis wrote:
> On Thu, Sep 04, 2003 at 12:17:35PM +0200, Csaba Nagy wrote:
> > [philosophical post regarding a missing feature of Postgres]
> >
> > I found there's no way to avoid failed inserts because of
> > unique constraint violations, causing automatic roll-back o
Harald Fuchs <[EMAIL PROTECTED]> writes:
> You can't. The only thing MySQL has to offer is
Actually I found two things related to this:
http://www.mysql.com/doc/en/INSERT.html
http://www.mysql.com/doc/en/REPLACE.html
You can do
INSERT INTO tab (...) VALUES (...) ON DUPLICATE KEY UPDATE col
On Thu, 2003-09-04 at 15:52, Greg Stark wrote:
>
> Csaba Nagy <[EMAIL PROTECTED]> writes:
>
> > This problem would be easily solved if the current transaction would not
> > be automatically rolled back on the failed insert. Given this, it would
> > be as easy as trying the insert, and if fails, d
Csaba Nagy <[EMAIL PROTECTED]> writes:
> This problem would be easily solved if the current transaction would not
> be automatically rolled back on the failed insert. Given this, it would
> be as easy as trying the insert, and if fails, do the update.
Yeah, that would be nested transactions, it'
On 4 Sep 2003 at 12:17, Csaba Nagy wrote:
> This problem would be easily solved if the current transaction would not
> be automatically rolled back on the failed insert. Given this, it would
> be as easy as trying the insert, and if fails, do the update.
That violates definition of a transaction.
[philosophical post regarding a missing feature of Postgres]
Hi all,
This is exactly the problem I'm facing right now, and I found there's no
good solution to this in postgres.
Basically I have a complex database operation, which spans a transaction
across multiple simple DB operations which can
10 matches
Mail list logo
