> -Original Message-
> From: Dmitry Yemanov [mailto:firebi...@yandex.ru]
> Sent: Miércoles, 10 de Junio de 2015 15:40
> >
> > With the old logic, the result is one. With the new logic,
> the result is two
> > becaise we get the direct and indirect effects.
>
> I doubt the new logic would
10.06.2015 23:28, Claudio Valderrama C. wrote:
>
> I would like to be able to know that I'm dealing with MERGE or any other
> statement that can lead to an update and/or insert. Adding
> inserts+updates+deletes is not a problem (indeed, it's simpler code), but
> it's a departure of the traditional
10.06.2015 22:28, Claudio Valderrama C. wrote:
> With the old logic, the result is one. With the new logic, the result is two
> becaise we get the direct and indirect effects.
Is it really the case? I never saw trigger's actions to be shown in result
of
isc_info_sql_records. Was I just lucky?
> -Original Message-
> From: Dmitry Yemanov [mailto:firebi...@yandex.ru]
> Sent: Martes, 09 de Junio de 2015 6:19
>
> 09.06.2015 13:11, Dimitry Sibiryakov wrote:
> >
> > ISQL would better always report "Rows affected" as a sum of
> all three components of
> > info response: inserts+upda
09.06.2015 15:23, Simonov Denis wrote:
>> We could add a new info tag to return the internal ROWS_AFFECTED value,
>> so that ISQL would not need to rely on separate I/U/D counters.
>
> Then also add context variables to obtain these counters
Any good example why you would need them in PSQL?
Dmi
Dmitry Yemanov писал(а) в своём письме Tue, 09 Jun
2015 12:07:39 +0300:
> 09.06.2015 07:13, Claudio Valderrama C. wrote:
>>
>> Ideas?
>
> We could add a new info tag to return the internal ROWS_AFFECTED value,
> so that ISQL would not need to rely on separate I/U/D counters.
>
Then also add co
09.06.2015 13:11, Dimitry Sibiryakov wrote:
>
> ISQL would better always report "Rows affected" as a sum of all three
> components of
> info response: inserts+updates+deletes.
Sounds as a good short-term solution. Does anyone see problems with this
approach?
Dmitry
-
09.06.2015 11:02, Alex Peshkoff wrote:
> May be not throw but slightly extend? In non-merge INSERT update count
> should always be 0. Can we always take into an account non-zero update
> count for insert-like-reported statements?
ISQL would better always report "Rows affected" as a sum of all t
On 06/09/2015 12:07 PM, Dmitry Yemanov wrote:
> 09.06.2015 07:13, Claudio Valderrama C. wrote:
>> Ideas?
> We could add a new info tag to return the internal ROWS_AFFECTED value,
> so that ISQL would not need to rely on separate I/U/D counters.
>
> Given that ISQL already uses the new API, maybe we
09.06.2015 07:13, Claudio Valderrama C. wrote:
>
> Ideas?
We could add a new info tag to return the internal ROWS_AFFECTED value,
so that ISQL would not need to rely on separate I/U/D counters.
Given that ISQL already uses the new API, maybe we could even surface
such an info request directly v
On 06/09/2015 07:13 AM, Claudio Valderrama C. wrote:
> Hello, I want to hear opinions on this:
>
> currently, MERGE is always reported as this value of statement type:
> #define isc_info_sql_stmt_insert 2
>
> It seems to be always an insert statement for the engine. So far so good.
> Now,
Hello, I want to hear opinions on this:
currently, MERGE is always reported as this value of statement type:
#define isc_info_sql_stmt_insert 2
It seems to be always an insert statement for the engine. So far so good.
Now, please look at isql's process_record_count():
because the input p
12 matches
Mail list logo
