[Firebird-devel] [FB-Tracker] Created: (CORE-4835) CLONE -GBAK crashes / freeze Firebird server on restore over existing database

2015-06-09 Thread Darko (JIRA)
CLONE -GBAK crashes / freeze Firebird server on restore over existing database -- Key: CORE-4835 URL: http://tracker.firebirdsql.org/browse/CORE-4835 Project: Firebird Core

[Firebird-devel] [FB-Tracker] Created: (CORE-4834) GBAK crashes / freeze Firebird server on restore over existing database

2015-06-09 Thread Darko (JIRA)
GBAK crashes / freeze Firebird server on restore over existing database --- Key: CORE-4834 URL: http://tracker.firebirdsql.org/browse/CORE-4834 Project: Firebird Core Issue

Re: [Firebird-devel] Problem with MERGE

2015-06-09 Thread Dmitry Yemanov
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

Re: [Firebird-devel] Lucene: The Good Parts via hackernews

2015-06-09 Thread marius adrian popa
We will wait your patches seems to be the safe path :) C++ port of Lucene seems to be old version 3.0 with no intention of upgrading On Tue, Jun 9, 2015 at 9:34 AM, Roman Simakov wrote: > Hi! > > 2015-06-08 12:00 GMT+03:00 marius adrian popa : > > I saw at the firebird conference that Red Datab

Re: [Firebird-devel] Problem with MERGE

2015-06-09 Thread Simonov Denis
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

Re: [Firebird-devel] Problem with MERGE

2015-06-09 Thread Dmitry Yemanov
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 -

Re: [Firebird-devel] Problem with MERGE

2015-06-09 Thread Dimitry Sibiryakov
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

Re: [Firebird-devel] Problem with MERGE

2015-06-09 Thread Alex Peshkoff
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

Re: [Firebird-devel] Problem with MERGE

2015-06-09 Thread Dmitry Yemanov
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

Re: [Firebird-devel] Problem with MERGE

2015-06-09 Thread Alex Peshkoff
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,

Re: [Firebird-devel] [FB-Tracker] Commented: (CORE-4821) grant create database to ROLE doesn`t work: "no permission for CREATE access to DATABASE ..."

2015-06-09 Thread Alex Peshkoff
On 06/09/2015 08:16 AM, Pavel Zotov (JIRA) wrote: > [ > http://tracker.firebirdsql.org/browse/CORE-4821?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=29573#action_29573 > ] > > Pavel Zotov commented on CORE-4821: > ---