[tarantool-patches] Re: [PATCH v1 1/3] box: rfc for stacked diagnostic area in Tarantool

[Konstantin Osipov]

* Alexander Turenko <alexander.turenko at tarantool.org> [19/08/09 10:11]:
> > 
> > > 
> > > Maybe we should use 'warnings' term here if this feature is intended to
> > > be used for SQL warnings. If we want to use the proposed mechanics for
> > > warnings, then my proposal re using 'cause' term looks doubtful. Don't
> > > sure whether we should introduce some kind of warnings list for the
> > > diagnostic area or reuse 'cause' / 'parent' / ... field of struct error.
> 
> This is most confusing part for me. Say, we want to set a warning re
> precision loss during execution a SQL query. The response will be
> successful. There will not be an error to wrap this warning. How to
> store the warning (it looks as a query-local object) and how to show it
> in the response (in the binary protocol)?
> 
> Another case: we emit a warning re precission loss and an error occurs
> afterwards during the query execution (say, a constraint violation). The
> warning is not a reason / cause / parent for the error and it is not
> logical to using our current terms for this case.

Warnings are an entirely different beast to stacked errors. 

When we get to supporting warnings, this will be a separate object
in the diagnostics.

> We want to support SQL stacked diagnostics and it seems that the current
> proposal does not move us forward to them. I had read mysql docs on
> that, but I hope the standard described quite same thing:
> https://dev.mysql.com/doc/refman/5.6/en/diagnostics-area.html
> 
> I think we need at least keep SQL stacked diagnostics in a mind and
> explicitly decide whether we'll going (a bit?) forward to support them
> within this issue / proposal / discussion.

Yes.

-- 
Konstantin Osipov, Moscow, Russia