Em 06/05/2017 11:15, Vlad Khorsun escreveu:
> 06.05.2017 15:15, livius wrote:
>>
>>> Yes, but we should avoid to write whole novels at SQL statements ;)
>>
>> Agree - but to fast chice is also not good
>
>Could you offer better syntax ?
>
>>> It have no sence (if i understand you :) )
>> Mayb
06.05.2017 15:15, livius wrote:
>
>> Yes, but we should avoid to write whole novels at SQL statements ;)
>
> Agree - but to fast chice is also not good
Could you offer better syntax ?
>> It have no sence (if i understand you :) )
> Maybe, but it should be prohibited in code or designed to do
Awesome! :)
On 2017.04.21. 1:30, Adriano dos Santos Fernandes wrote:
> Em 20/04/2017 17:53, Vlad Khorsun escreveu:
>> Also it is necessary
>> to teach engine to use that metadata (instead of current one) within
>> attachment
>> working "in the past".
>>
> I'm doing a prototype implementation of t
Em 20/04/2017 17:53, Vlad Khorsun escreveu:
> Also it is necessary
> to teach engine to use that metadata (instead of current one) within
> attachment
> working "in the past".
>
I'm doing a prototype implementation of this for active transactions,
i.e., the things I mentioned in this thread star
20.04.2017 10:12, Molnár Attila wrote:
> +1 for this feature. I would be very happy for this. Also it would be
> awesmone if this consistent view were accessible later in time (this
> woudl mean garbage collection blocking).
Blocking of GC is the easiest part of this task. One need also to pres
>This statement i not understand. Do you speak about transaction ? Or
>about
Transaction.
> statement\cursor ? If later, why do you can't remember id of last fetched
> row
> and start next fetch from this position ?
That's what we do now, in a nutshell. The problem is of course to have
t
20.04.2017 9:36, Jiří Činčura wrote:
>> Could you explain, please ?
>
> Sure. There's a part of our system that reads data and sends these over
> the internet. Given the deployments on the customer side the internet is
> often very very slow (<100kBps sometimes), so we decided to not keep
> tr
19.04.2017 16:35, Dimitry Sibiryakov wrote:
> 19.04.2017 14:12, Vlad Khorsun wrote:
>> It give nothig to readers
>
> Not quite so. When array binding used with select, client can send
> request for new
> packet before it start tossing record values into user buffers and this way
> work i
