It looks like we managed to access SqlInsert#isUpsert just by
considering the original SqlNode while processing the plan
https://github.com/diennea/herddb/pull/582
Having it in the Logical Plan would be better, but there is no need to
complicate things by now.
In my case UPSERT is to be executed a
The fact that PostgreSQL implements MERGE and “INSERT … ON CONFLICT” (so-called
UPSERT) differently with regard to consistency is an implementation detail in
PostgreSQL, and I refuse to accept it as rationale for what we do in Calcite.
(If we try to emulate the behavior of systems that suck… wel
Il Mer 18 Mar 2020, 08:35 Christian Beikov ha
scritto:
> I'd argue that these technical details are in fact the reason why this
> is a different functionality, that deserves special handling.
>
> I expect an upsert statement like `INSERT INTO tbl(a, b) VALUES(1, 2) ON
> CONFLICT DO NOTHING` to ne
I'd argue that these technical details are in fact the reason why this
is a different functionality, that deserves special handling.
I expect an upsert statement like `INSERT INTO tbl(a, b) VALUES(1, 2) ON
CONFLICT DO NOTHING` to never produce a constraint violation.
This is functionally diff
I don't think there's a significant difference between the UPSERT and
MERGE. The differences are in marketing (which keyword to use) and in
technical details (e.g. concurrency semantics). Not worth splitting a
core concept over. We spend a lot of effort keeping like-things-like.
On Tue, Mar 17, 20
AFAIK MERGE has different concurrency semantics than what some DBMS call
UPSERT. PostgreSQL for example has a guaranteed insert or update
semantics whereas MERGE could end with constraint violation errors:
https://wiki.postgresql.org/wiki/UPSERT
Maybe it's worth adding that to the relational m
Il Lun 16 Mar 2020, 23:55 Julian Hyde ha scritto:
> Change the unparse operation for the dialect so that you generate UPSERT
> rather than MERGE.
>
> IIRC we did this for another dialect - maybe Phoenix.
>
Julian,
In my case (HerdDB) I need to see the presence of UPSERT in the RelNode
(Enumerabl
Change the unparse operation for the dialect so that you generate UPSERT rather
than MERGE.
IIRC we did this for another dialect - maybe Phoenix.
Julian
> On Mar 16, 2020, at 1:22 AM, Enrico Olivelli wrote:
>
> Il Lun 16 Mar 2020, 09:06 Stamatis Zampetakis ha
> scritto:
>
>> Hi Enrico,
>
Il Lun 16 Mar 2020, 09:06 Stamatis Zampetakis ha
scritto:
> Hi Enrico,
>
> I have the impression that UPSERT is currently supported only at the parser
> level [1] so it seems normal that you don't find something relevant in
> LogicalTableModify etc. Note that the SQL standard equivalent is the ME
Hi Enrico,
I have the impression that UPSERT is currently supported only at the parser
level [1] so it seems normal that you don't find something relevant in
LogicalTableModify etc. Note that the SQL standard equivalent is the MERGE
statement [2] but this also seems to be supported only at the
par
Hi,
I am trying to use UPSERT but it seems to me that in TableModify (or
best LogicalTableModify or EnumerableTableModify) there is no way to
distinguish an INSERT from an UPSERT.
Am I missing something?
Regards
Enrico
11 matches
Mail list logo
