| From: | "Jim C(dot) Nasby" <jnasby(at)pervasive(dot)com> |
|---|---|
| To: | Bruce Momjian <pgman(at)candle(dot)pha(dot)pa(dot)us> |
| Cc: | Tom Lane <tgl(at)sss(dot)pgh(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 04:04:11 |
| Message-ID: | 20051116040411.GI44860@pervasive.com |
| Views: | Raw Message | Whole Thread | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-hackers |
On Tue, Nov 15, 2005 at 07:16:21PM -0500, Bruce Momjian wrote:
> Tom Lane wrote:
> > Josh Berkus <josh(at)agliodbs(dot)com> writes:
> > > But even REPLACE requires predicate locking. There's no real way to get
> > > around it.
> >
> > The point though is that REPLACE is restricted to a type of predicate
> > narrow enough to be enforced through a unique-index mechanism, and so
> > it's implementable without solving the general case of predicate
> > locking.
> >
> > Predicate locking for narrow cases isn't very hard; it's the general
> > case of arbitrary predicates that's hard.
>
> My feeling is we should implement MERGE for the limited cases we can,
> and throw an error for cases we can not (or require table locking), and
> then see what reports we get from users.
We should probably throw a notice or warning if we go to a table lock,
too.
--
Jim C. Nasby, Sr. Engineering Consultant jnasby(at)pervasive(dot)com
Pervasive Software http://pervasive.com work: 512-231-6117
vcard: http://jim.nasby.net/pervasive.vcf cell: 512-569-9461
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Tom Lane | 2005-11-16 04:04:59 | Re: OS X 7.4 failure |
| Previous Message | Jim C. Nasby | 2005-11-16 03:52:21 | Re: bind variables, soft vs hard parse |