From: | Petr Jelinek <pjmodos(at)seznam(dot)cz> |
---|---|
To: | Peter Eisentraut <peter_e(at)gmx(dot)net>, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>, jd(at)commandprompt(dot)com |
Cc: | PostgreSQL-development <pgsql-hackers(at)postgresql(dot)org> |
Subject: | Re: MERGE vs REPLACE |
Date: | 2005-11-13 22:32:47 |
Message-ID: | 4377BF0F.4090201@seznam.cz |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
Peter Eisentraut wrote:
>
> In that regard, MERGE is quite flexible, but MERGE doesn't address the
> point of REPLACE, because MERGE requires *two* tables as input, whereas
> REPLACE only takes *one*. Unless someone can show that you can trick
> MERGE into doing the REPLACE job anyway, we're not discussing the same
> thing.
>
I am really not db expert and I don't have copy of sql standard but you
don't need to use 2 tables I think - USING part can also be subquery
(some SELECT) and if I am right then you could simulate what REPLACE
does because in PostgreSQL you are not forced to specify FROM clause in
SELECT. So you could in theory do
MERGE INTO tablename USING (SELECT 1 AS myid) ON (tablename.id = myid) ...
But I am not sure if this is what you want.
--
Regards
Petr Jelinek (PJMODOS)
From | Date | Subject | |
---|---|---|---|
Next Message | Martijn van Oosterhout | 2005-11-13 22:56:43 | Re: MERGE vs REPLACE |
Previous Message | Kevin Brown | 2005-11-13 21:50:32 | Re: SIGSEGV taken on 8.1 during dump/reload |