| From: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
|---|---|
| To: | daveg <daveg(at)sonic(dot)net> |
| Cc: | Christopher Kings-Lynne <chriskl(at)familyhealth(dot)com(dot)au>, "Jim C(dot) Nasby" <jnasby(at)pervasive(dot)com>, Bruce Momjian <pgman(at)candle(dot)pha(dot)pa(dot)us>, josh(at)agliodbs(dot)com, pgsql-hackers(at)postgresql(dot)org, Jaime Casanova <systemguards(at)gmail(dot)com>, Peter Eisentraut <peter_e(at)gmx(dot)net> |
| Subject: | Re: MERGE vs REPLACE |
| Date: | 2005-11-16 21:51:07 |
| Message-ID: | 11204.1132177867@sss.pgh.pa.us |
| Views: | Raw Message | Whole Thread | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-hackers |
daveg <daveg(at)sonic(dot)net> writes:
> I agree, but would like to relax the primary key requirement to simply
> a unique index. I can see use cases for unique so long as not null keys,
> so it would be nice if the MERGE operation would work for these. As nulls
> are not "equal" anyway this doesn't seem to do too much violence to the
> semantics.
But a "unique" key doesn't guarantee that there's only one matching row,
so ISTM you're right back to needing a predicate lock if you do that.
regards, tom lane
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Joe Conway | 2005-11-16 21:57:42 | Re: Some array semantics issues |
| Previous Message | daveg | 2005-11-16 21:31:28 | Re: MERGE vs REPLACE |