| From: | daveg <daveg(at)sonic(dot)net> |
|---|---|
| To: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
| 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:31:28 |
| Message-ID: | 20051116213128.GK22209@sonic.net |
| Views: | Raw Message | Whole Thread | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-hackers |
On Wed, Nov 16, 2005 at 09:49:28AM -0500, Tom Lane wrote:
> I think we should do REPLACE-like functionality that simply fails if the
> match condition isn't equality on a primary key. If we can use SQL-spec
> MERGE syntax for this, that's fine, but let's not think in terms of
> silently changing to a stronger table lock and a much slower
> implementation when the condition isn't a primary key. That's a whole
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.
-dg
--
David Gould daveg(at)sonic(dot)net
If simplicity worked, the world would be overrun with insects.
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Tom Lane | 2005-11-16 21:51:07 | Re: MERGE vs REPLACE |
| Previous Message | Dave Cramer | 2005-11-16 21:30:09 | PANIC: could not locate a valid checkpoint record |