Lincoln Yeoh wrote:
> At 01:51 AM 7/2/2003 -0400, Mike Mascari wrote:
>
>> > Maksim Likharev wrote:
>> >>I do not know how that will work for PG, but in Microsoft SQL Server
>> >>you can do following
>> >>BEGIN TRANSACTION
>> >>UPDATE [val] = [val]
>> >> WHERE
>> >>INSERT ...
>> >>COMMI
At 01:51 AM 7/2/2003 -0400, Mike Mascari wrote:
> Maksim Likharev wrote:
>>I do not know how that will work for PG, but in Microsoft SQL Server
>>you can do following
>>BEGIN TRANSACTION
>>UPDATE [val] = [val]
>> WHERE
>>INSERT ...
>>COMMIT TRANSACTION
>>
>>so basically by updating specif
Jean-Christian Imbeault wrote:
> Maksim Likharev wrote:
>
>>Finding if the duplicate value exists and inserting if not.
>
> Ok, thanks but I think it is still vulnerable to a race condition.
>
>>I do not know how that will work for PG, but in Microsoft SQL Server
>>you can do following
>>BEGIN T
On Wednesday 02 July 2003 02:58, Jean-Christian Imbeault wrote:
> Alvaro Herrera wrote:
> > No, only the "second" one will fail (though it's difficult which one is
> > the second)
>
> From:
>
> http://marc.theaimsgroup.com/?l=postgresql-general&m=105656988915991&w=2
>
> I
On Wed, Jul 02, 2003 at 12:08:56 +0900,
Jean-Christian Imbeault <[EMAIL PROTECTED]> wrote:
> TAL=# insert into b select 'b', select 'b';
> ERROR: parser: parse error at or near "select" at character 27
You probably want:
insert into b select 'b', 'b';
---(end of broadca
On Tuesday 01 July 2003 11:08 pm, Jean-Christian Imbeault wrote:
> Reuben D. Budiardja wrote:
> > INSERT INTO mytable
> > SELECT 'value1', 'value2'
> >WHERE NOT EXISTS
> > (SELECT NULL FROM mytable
> > WHERE mycondition)
>
> Thank you to every
Reuben D. Budiardja wrote:
>
> INSERT INTO mytable
> SELECT 'value1', 'value2'
>WHERE NOT EXISTS
> (SELECT NULL FROM mytable
> WHERE mycondition)
Thank you to everyone who helped out on my question. I am trying to
implement the abov
On Tuesday 01 July 2003 09:25 pm, Jean-Christian Imbeault wrote:
> Reuben D. Budiardja wrote:
> > No, onlu *one* of them will fail, but yes, the other will then generate
> > error. So it really is a trade off. Another way would be to lock the
> > table, as other has suggested. But then
On Tue, Jul 01, 2003 at 06:48:29PM -0700, Dann Corbit wrote:
> I assume that PostgreSQL would simply time out both transactions if it
> happened in a deadly-embrace pair?
>
> I searched the PG docs, but could not find a clear answer.
No, the deadlock will the detected and one of the transactions
> -Original Message-
> From: Alvaro Herrera [mailto:[EMAIL PROTECTED]
> Sent: Tuesday, July 01, 2003 6:37 PM
> To: Jean-Christian Imbeault
> Cc: [EMAIL PROTECTED]; [EMAIL PROTECTED]
> Subject: Re: [GENERAL] Duplicate key insert question
>
>
> On Wed, Jul 0
Alvaro Herrera wrote:
>
> Well, he is right. One will fail, the other will not. The race
> condition is for the application. If you want to ignore it, you can do
> that, but there _will_ be an ERROR thrown and the transaction will be
> aborted.
Ah ... then maybe this solut
On Tue, Jul 01, 2003 at 06:26:08PM -0700, Dann Corbit wrote:
> > But you should try to use a sequence if at all possible to avoid all
> > these problems.
>
> Does not really avoid the named issue.
>
> Suppose that you have a dictionary of working part numbers (e.g. Boeing
> might have 3 million
On Wed, Jul 02, 2003 at 10:25:54AM +0900, Jean-Christian Imbeault wrote:
> Reuben D. Budiardja wrote:
> >
> > No, onlu *one* of them will fail, but yes, the other will then generate error.
> > So it really is a trade off. Another way would be to lock the table, as other
> > has suggested. But th
Reuben D. Budiardja wrote:
>
> No, onlu *one* of them will fail, but yes, the other will then generate error.
> So it really is a trade off. Another way would be to lock the table, as other
> has suggested. But then there is disadvantages to that also.
Really? I just got a pos
>> -Original Message-
>> From: Alvaro Herrera [mailto:[EMAIL PROTECTED]
>> Sent: Tuesday, July 01, 2003 5:51 PM
>> To: Jean-Christian Imbeault
>> Cc: [EMAIL PROTECTED]; [EMAIL PROTECTED]
>> Subject: Re: [GENERAL] Duplicate key insert question
>
Alvaro Herrera wrote:
>
> The thread is here:
> http://groups.google.com/groups?hl=en&lr=&ie=UTF-8&oe=UTF-8&threadm=3A4D6116.1A613402%40mascari.com&rnum=1&prev=/groups%3Fq%3DMike%2BMascari%2BINSERT%2BNOT%2BEXISTS%26ie%3D
Thanks!
> The solution is not correct in that there _i
On Tuesday 01 July 2003 08:45 pm, Jean-Christian Imbeault wrote:
> Reuben D. Budiardja wrote:
> > Hi, not sure if this is answering your question, but I just asked similar
> > questions here. I asked about using INSERT WHERE NOT EXISTS (which you
> > can do in PostgreSQL). Here is what
On Wed, Jul 02, 2003 at 09:58:28AM +0900, Jean-Christian Imbeault wrote:
> Alvaro Herrera wrote:
> >
> > No, only the "second" one will fail (though it's difficult which one is
> > the second)
>
> I couldn't get the link to work so I couldn't read why Tom shot it down.
> But if Tom shot down this
Maksim Likharev wrote:
>
> Finding if the duplicate value exists and inserting if not.
Ok, thanks but I think it is still vulnerable to a race condition.
> I do not know how that will work for PG, but in Microsoft SQL Server
> you can do following
> BEGIN TRANSACTION
>
values, commit transaction.
-Original Message-
From: Jean-Christian Imbeault [mailto:[EMAIL PROTECTED]
Sent: Tuesday, July 01, 2003 5:47 PM
To: Maksim Likharev
Cc: [EMAIL PROTECTED]
Subject: Re: [GENERAL] Duplicate key insert question
Maksim Likharev wrote:
Alvaro Herrera wrote:
>
> No, only the "second" one will fail (though it's difficult which one is
> the second)
From:
http://marc.theaimsgroup.com/?l=postgresql-general&m=105656988915991&w=2
Ian Barwick wrote:
[...]
I proposed that same solution 3 years
21 matches
Mail list logo
