Peter Eisentraut <[EMAIL PROTECTED]> writes:
> It seems to me that it has always been implicitly assumed around here
> that the MERGE command would be a substitute for a MySQL-like REPLACE
> functionality. After rereading the spec it seems that this is not the
> case. MERGE always operates on two different tables, which REPLACE
> doesn't do.
Normally I'd plump for following the standard ... but AFAIR, we have had
bucketloads of requests for REPLACE functionality, and not one request
for spec-compatible MERGE. If, as it appears, full-spec MERGE is also a
whole lot harder and slower than REPLACE, it seems that we could do
worse than to concentrate on doing REPLACE for now. (We can always come
back to MERGE some other day.)
regards, tom lane
---------------------------(end of broadcast)---------------------------
TIP 9: In versions below 8.0, the planner will ignore your desire to
choose an index scan if your joining column's datatypes do not
match
