Re: [Firebird-devel] Improve release filenames

25.08.2022 04:15, Adriano dos Santos Fernandes wrote: Here is my updated proposal based on the discussion so far: Firebird-5.0.0.2816-0-windows-x86-withDebugSymbols.exe Firebird-5.0.0.2816-0-windows-x86-withDebugSymbols.zip Firebird-5.0.0.2816-0-windows-x86.exe

Re: [Firebird-devel] Improve release filenames

24.08.2022 15:35, Jiří Činčura wrote: I would unify the `pdb`, `debuginfo`, etc. into simple `debug` suffix. Agreed. Dmitry Firebird-Devel mailing list, web interface at https://lists.sourceforge.net/lists/listinfo/firebird-devel

Re: [Firebird-devel] Current value for parallel workers

16.08.2022 13:02, Jiří Činčura wrote: Session context variable seems to be a good fit. Monitoring table looks like overkill. I think DBA may want a monitoring table (MON$WORKERS?) that shows how many workers are currently active, what attachment are they bound to, and what task

Re: [Firebird-devel] New statement: EXECUTE SQL

15.08.2022 20:42, Vlad Khorsun wrote: Also, I don't like 'sql' word, especially after 'execute statement' and 'execute block'. Too much, as for me :) Syntax with 'with' instead of 'execute sql' looks much better to me, but it is already used in CTE's, thus it seems as not the best choice :(

Re: [Firebird-devel] Version of 3.0 snapshots

29.06.2022 13:31, Gabor Boros wrote: 3.0.10 already released and the snapshots still show 3.0.10. Please increase the revision number. Thank you! Done, thanks for reminding! Dmitry Firebird-Devel mailing list, web interface at https://lists.sourceforge.net/lists/listinfo/firebird-devel

Re: [Firebird-devel] Stdin redirection with pipe in Windows ISQL

15.06.2022 22:56, Adriano dos Santos Fernandes wrote: In Linux, when we do: echo "select 1 from rdb\$database; select 2 from rdb\$database;" | isql t.fdb It shows: CONSTANT 1 CONSTANT 2 In Windows, echo select 1 from

Re: [Firebird-devel] Record storage

09.06.2022 16:18, Adriano dos Santos Fernandes wrote: 09.06.2022 15:16, Adriano dos Santos Fernandes wrote: Yes, it should work. However, I'm not going to remove the limit until we introduce a denser compression. Also, we have a number of places where records is stored unpacked in memory

Re: [Firebird-devel] Record storage

09.06.2022 15:58, Dmitry Yemanov wrote: (2) skip padding bytes A separate but interesting question is whether we need alignment (and thus padding bytes) at all. Most of our installations are little-endian and it does not crash on unaligned data access. Moreover, modern CPUs access aligned

Re: [Firebird-devel] Record storage

09.06.2022 15:16, Adriano dos Santos Fernandes wrote: With some frequency people ask me why UTF-8 is slower than single byte charsets. The thing is, they have something using, for example, VARCHAR(30) CHARACTER SET WIN1252 and convert to VARCHAR(30) CHARACTER SET UTF8, test with the same data

Re: [Firebird-devel] Add scroll fetch support in legacy API?

04.06.2022 15:07, Mark Rotteveel wrote: Currently scroll fetch is only exposed in the OO API. Any plans for exposing it in the legacy API Nope, we have an agreement to not extending the legacy API with new features. (e.g. isc_dsql_fetch_scroll / fb_dsql_fetch_scroll)? That's not

Re: [Firebird-devel] Unused but still handled DPB items

16.05.2022 18:51, Dimitry Sibiryakov пишет:   Hello All. Shouldn't code for handling isc_dpb_journal, isc_dpb_old_file, etc cleaned out or someone have plans for their reuse? I don't think any DPB code can be reused, unless the new behaviour completely matches the originally intended one

Re: [Firebird-devel] Firebird and DSQL Scrollable Cursors

28.04.2022 14:31, Mark Rotteveel wrote: I notice that if I get the INF_RECORD_COUNT with op_info_cursor before the first fetch, I will get the record count, but the subsequent fetch will fail with a Dynamic SQL Error; SQLDA error; Data type unknown; at SQLVAR index 0 [SQLState:07002, ISC

Re: [Firebird-devel] Firebird and DSQL Scrollable Cursors

22.04.2022 14:49, Mark Rotteveel wrote: 28.11.2021 14:45, Mark Rotteveel wrote: 3) "row count" makes it possible to know the position after fetchLast() and everything else could be calculated locally by the client library, thus making the server-supported "current position" totally

Re: [Firebird-devel] Status of 3.0.10

13.04.2022 17:11, Pavel Cisar wrote: because 3.0.9 has significant regression (#7137 - we've got multiple reports from large affected and unhappy users), I'd like ask what are the prospect to release v3.0.10 soon. BTW, it would also address contracted collation performance issues that we

Re: [Firebird-devel] FB4.0 - no current record for fetch operation

26.03.2022 11:53, Omacht András wrote: I have a test case which running fine on 2.5 and 3.0 but faild on 4.0 with „no current record for fetch operation”. Unfortunately I could not reproduce it as a simple case, but I can send the database in private. Please send it to me. Dmitry

Re: [Firebird-devel] Local tables

15.03.2022 21:43, Adriano dos Santos Fernandes wrote: In fact, what you priorly define as LT is IMO "declared" LTT. I had that impression before read the standard, but then I changed my opinion. "Part 4: Persistent Stored Modules (SQL/PSM)" is about PSQL, AFAIU. It includes: "12.8 " that

Re: [Firebird-devel] Local tables

15.03.2022 20:31, Alex Peshkoff via Firebird-devel wrote: For me, "created" LTT is similar to GTT (i.e. stored in the schema) but with data isolated per request (per PSQL routine). I'd consider about CREATE'd LTT as attachment-private object. I see no need to store its definition at the

Re: [Firebird-devel] Local tables

15.03.2022 20:17, Vlad Khorsun wrote: For me, "created" LTT is similar to GTT (i.e. stored in the schema) but with data isolated per request (per PSQL routine). I'd consider about CREATE'd LTT as attachment-private object. I see no need to store its definition at the persistent schema.

Re: [Firebird-devel] Local tables

15.03.2022 17:14, Adriano dos Santos Fernandes wrote: As part of "Support multiple rows for DML RETURNING (#6815)" feature, BLR verbs for "local table" were created. Local tables (LT) as defined there works outside transaction control. For #6815 this does not matter, but I want to add LT

Re: [Firebird-devel] Local tables

15.03.2022 18:03, Kjell Rilbe wrote: From a linguistic point of view I find "declared" to be a nonsense qualification of "table". Aren't all tables declared in a sense? Maybe, but this is what SQL spec suggests. In PSQL, we have any locals syntactically "declared" -- DECLARE VARIABLE,

Re: [Firebird-devel] Roadmap, Planning Board, version of 4.0 snapshots

03.03.2022 12:38, Gabor Boros wrote: 3.0.9 already released, please update the Roadmap page. 5.0 Alpha not released in January, please update the Planning Board page. 4.0.1 already released but the snapshot's version still 4.0.1. Updated, thanks. Dmitry Firebird-Devel mailing list, web

Re: [Firebird-devel] Compiled statement cache

03.03.2022 20:19, Alex Peshkoff via Firebird-devel wrote: I think there are two possible ways: - Timeout of cached statement (counting from its first appearance in cache, not last usage) Yes, re-preparing all statements once per relatively big timeout should not cause visible performance

Re: [Firebird-devel] Statement::verifyAccess of internal requests

01.03.2022 21:33, Adriano dos Santos Fernandes wrote: Do we have any good reason to make this method do for internal requests everything it does for user's statement? Or could we start it with this? void Statement::verifyAccess(thread_db* tdbb) { if (flags & FLAG_INTERNAL)

Re: [Firebird-devel] Knowing whether fbclient supports isc_dpb_utf8_filename

01.03.2022 14:56, Jiří Činčura wrote: void ISC_EXPORT isc_get_client_version ( ISC_SCHAR *); int ISC_EXPORT isc_get_client_major_version (); int ISC_EXPORT isc_get_client_minor_version (); Great! How could I miss it??? Sorry for disappointing you, but they not gonna be any helpful, as

Re: [Firebird-devel] Compiled statement cache

26.02.2022 17:14, Adriano dos Santos Fernandes wrote: I do want to define default cache size. I'm thinking in 2M. Comments? We need to start with something, so why not. However, it would be helpful to know what are the "common" statement sizes for tables, procedures, etc. Of course, table

Re: [Firebird-devel] INT64 and index keys

21.02.2022 20:05, Alex Peshkoff via Firebird-devel wrote: This is possible way to fix a bug: https://github.com/FirebirdSQL/firebird/commit/7dd832f32e9669bcb3007dc675b3ee7cca6f6b7d New type of indexes is added and it works fine. I didn't look at the patch deeply yet, so the question: what

Re: [Firebird-devel] INT64 and index keys

16.02.2022 13:28, Dmitry Yemanov wrote: It looks so. Unless we miss something (Alex?), perhaps we need to add a runtime check that rejects key creation for INT128 values longer than 34 decimal digits. Thinking twice, an overflow error should already been raised when a longish INT128

Re: [Firebird-devel] INT64 and index keys

16.02.2022 13:24, Alex Peshkoff via Firebird-devel wrote: It looks so. Unless we miss something (Alex?), perhaps we need to add a runtime check that rejects key creation for INT128 values longer than 34 decimal digits. Thinking twice, an overflow error should already been raised when a

Re: [Firebird-devel] INT64 and index keys

16.02.2022 12:54, Dmitry Yemanov wrote: It looks so. Unless we miss something (Alex?), perhaps we need to add a runtime check that rejects key creation for INT128 values longer than 34 decimal digits. Thinking twice, an overflow error should already been raised when a longish INT128

Re: [Firebird-devel] INT64 and index keys

16.02.2022 12:19, Mark Rotteveel wrote: However, that was not my main point. My main point was that it sounds like an index format that was created for supporting DECFLOAT(34), and that it is not suitable for the full range of INT128 and NUMERIC/DECIMAL backed by INT128 (for the same reasons

Re: [Firebird-devel] INT64 and index keys

15.02.2022 18:37, Kjell Rilbe wrote: With respect, since I'm not in the dev team, I fail to see it as an important feature to avoid index rebuild when changing between integer and numeric column types: 1. Changing between such types must be pretty rare, at least on production databases.

Re: [Firebird-devel] INT64 and index keys

15.02.2022 14:41, Dimitry Sibiryakov wrote: Is "stored keys independent of the declared scale" a really useful and used feature? That's a separate but also good question. Double precision keys allow independence of both precision (within its range) and scale. AFAIU, the idea was to allow

[Firebird-devel] INT64 and index keys

All, Historically, we store most numerics as double precision inside index keys. It makes stored keys independent of the declared scale and allows both prefix and suffix compression. However, int64 keys (BIGINT and largish NUMERICs/DECIMALs) do not fit the double format without risk of

Re: [Firebird-devel] Dropping database default SQL SECURITY

14.02.2022 22:40, Roman Simakov wrote: I don't remember exactly why we decided to make it nullable. I suppose for more backward compatibility. If a client doesn't use it it will be NULL everywhere. Maybe the idea was to distinguish between legacy databases (restored without SQL SECURITY) and

Re: [Firebird-devel] Compiled statement cache

10.02.2022 20:18, Adriano dos Santos Fernandes wrote: We should have better strategy for request cache inside the statement. If they are cheap to create, it would make no sense to never destroy them like now. Looking at Statement::getRequest() I see it as dirty cheap, just a matter of few

Re: [Firebird-devel] Compiled statement cache

10.02.2022 19:54, Adriano dos Santos Fernandes wrote: I come with this requirement because verifyAccess is currently part of compilation. But as I said and Vlad also said, we can remove roles from key and verify (with verification cache) after get statement from cache. This would be better.

Re: [Firebird-devel] Compiled statement cache

10.02.2022 19:21, Dimitry Sibiryakov wrote: Only if such translation is made right. Remember charset introducers. They're a problem, but it may only cause a cache miss, not a false match, right? But apparently to transform the query before using it as a cache key is a right idea. Two

Re: [Firebird-devel] Compiled statement cache

10.02.2022 16:01, Adriano dos Santos Fernandes wrote: (Jrd)Statement is reused - new jrd_req are get from same statement. IIRC, the existing cache of internal requests preserves jrd_req's. Am I right that after the jrd_req->Statement refactoring the cost of creation of new jrd_req is

Re: [Firebird-devel] Compiled statement cache

08.02.2022 16:36, Adriano dos Santos Fernandes wrote: First what should be the statement key in the cache? I've peek these: - statement text - clientDialect - isInternalRequest - current client charset (as external engines may change it) Cannot the UTF8-translated SQL text (which is

Re: [Firebird-devel] Compiled statement cache

10.02.2022 15:57, Adriano dos Santos Fernandes wrote: If we need to take roles into an account - only for attachment with same USER. Even without shared cache, user can change its roles with SET ROLES and new prepared statements should work as before even when they were previously cached

Re: [Firebird-devel] Acquire lock for relation (XXX) failed

01.02.2022 17:11, Jiří Činčura wrote: session 1: CREATE INDEX ... ON VERY_BIG_TABLE (...); COMMIT; Can same be achieved by selects/insert/updates and some TPB settings (like i.e. isc_tpb_concurrency)? Sure, but with isc_tpb_consistency (not isc_tpb_concurrency). Dmitry Firebird-Devel

Re: [Firebird-devel] Acquire lock for relation (XXX) failed

01.02.2022 16:45, Jiří Činčura wrote: Hi *, What do I have to do to get an error "Acquire lock for relation (XXX) failed"? session 1: CREATE INDEX ... ON VERY_BIG_TABLE (...); COMMIT; session 2: INSERT INTO VERY_BIG_TABLE VALUES (..) -- in NO WAIT transaction Dmitry Firebird-Devel mailing

Re: [Firebird-devel] ExprNode::FLAG_VALUE

06.01.2022 17:13, Adriano dos Santos Fernandes wrote: See also: https://github.com/FirebirdSQL/firebird/issues/1355 https://github.com/FirebirdSQL/firebird/commit/626ab18c426fd32d482e02093e72e57330596174 Worth testing GROUP BY , ? Since v3 we must be safe. Aggregate stream allocates

Re: [Firebird-devel] Remove blr_parameter3

14.01.2022 16:52, Adriano dos Santos Fernandes wrote: Our code does not generate blr_parameter3. I propose to remove this code, commenting this verb for not immediate reuse. It looks like as it tries to put in the third parameter slot the maximum string length moved to the parameter. Do

Re: [Firebird-devel] ExprNode::FLAG_VALUE

06.01.2022 04:28, Adriano dos Santos Fernandes wrote: There is ExprNode::FLAG_VALUE ("Full value area required in impure space"), inherited from old (2.5) code base nod_value. It's set by sort subsystem and used only for parameters and variables. Initially it as also used for fields. But at

Re: [Firebird-devel] Firebird and DSQL Scrollable Cursors

20.12.2021 13:58, Dimitry Sibiryakov wrote: Even non-scrollable cursors can know total number of records if plan SORT is used Sort may be hidden inside other execution nodes, so it's not always as easy to know. I'd rather avoid returning (or not) info depending on the query plan. or

Re: [Firebird-devel] Firebird and DSQL Scrollable Cursors

Mark et al, > Looked at it again, and being able to get the total row count will work > for me. Is this information already available, or does this still need > to be implemented? What would you expect from the "row count" requested for a non-scrollable cursor? It cannot return the true count,

Re: [Firebird-devel] Firebird and DSQL Scrollable Cursors

19.12.2021 16:04, Mark Rotteveel wrote: Looked at it again, and being able to get the total row count will work for me. Is this information already available, or does this still need to be implemented? Implemented but not yet committed. I will post a pull request tomorrow. One last thing I

Re: [Firebird-devel] UDR for reading server configuration for Firebird QA

12.12.2021 01:21, Adriano dos Santos Fernandes wrote: If it does not return sensitive information, I see no problem in add it to examples UDR project. I like the idea about /examples, but the server configuration *is* sensitive information, if exposed to a non-DBA user. So the examples

Re: [Firebird-devel] Firebird and DSQL Scrollable Cursors

08.12.2021 13:49, Dimitry Sibiryakov wrote: Storing of fetched rows is unavoidable indeed but prefetch?.. Is it done in background or before returning of the first row to client even in embedded mode? The latter. But prefetch is done in small chunks, usually it does not hurt. Dmitry

Re: [Firebird-devel] Firebird and DSQL Scrollable Cursors

08.12.2021 12:37, Tony Whyman wrote: It would also be very useful to get rowcount returned for unidirectional cursors if that was readily possible. At present, it is only possible to get an accurate count of the number of rows in a cursor after you have fetched all of them. It cannot be

Re: [Firebird-devel] Firebird and DSQL Scrollable Cursors

28.11.2021 14:45, Mark Rotteveel wrote: We don't have anything like this. Theoretically, we could extend IRecordSet with something similar (although it would also require a protocol change), but the question is whether it's really needed. Personally, I don't see it useful per se. If users

Re: [Firebird-devel] Firebird and DSQL Scrollable Cursors

01.12.2021 16:07, Dimitry Sibiryakov wrote: Also if IResultSet is returned from IAttachment::openCursor() there is no (visible) IStatement at all. And I see the same problem for setCursorName() which is available only through IStatement. An oversight? Dmitry Firebird-Devel mailing

Re: [Firebird-devel] INF_database_info

30.11.2021 14:58, Roman Simakov wrote: isql after set stat returns some statistics of a query execution like Current memory = 10647136 Delta memory = 148432 Max memory = 10728544 Elapsed time = 162.476 sec Cpu = 0.000 sec Buffers = 1024 Reads = 332280 Writes = 0 Fetches = 70584692 Actually

Re: [Firebird-devel] Plans for 4.0.1

01.12.2021 14:25, Pavel Cisar wrote: would be 4.0.1 released in December, January or later? I'd like to have it released in December. I don't see any showstoppers and plan to commit my own pending parts during a week or so. Dmitry Firebird-Devel mailing list, web interface at

Re: [Firebird-devel] Plans for 3.0.8

01.12.2021 14:01, Gabor Boros wrote: Please update the Roadmap page: https://firebirdsql.org/en/roadmap Done. Dmitry Firebird-Devel mailing list, web interface at https://lists.sourceforge.net/lists/listinfo/firebird-devel

Re: [Firebird-devel] Firebird and DSQL Scrollable Cursors

28.11.2021 14:37, Dimitry Sibiryakov wrote: And it doesn't need to be a dedicated method of IResultSet. Something generic and easily extendable like IResultSet::getInfo() would be enough. Given that any DSQL statement cannot have multiple result sets, I doubt IResultSet::getInfo() is really

Re: [Firebird-devel] WNET future

30.11.2021 22:47, Leyne, Sean wrote: With dropping this option ability to open database file from mounted network drive also will be dropped (or at least must be heavily reworked). Why? Support for being a WNET server/listening for WNET connections should be un-related to accessing

Re: [Firebird-devel] WNET future

30.11.2021 20:10, Dimitry Sibiryakov wrote: Then reworking seems easy. Just preserve ISC_analyze_pclan() to extract the lanman hostname and then try connecting via TCP. The question is port number. It is changed more frequently than pipe name. True, but the same applies to NFS shares.

Re: [Firebird-devel] WNET future

30.11.2021 20:01, Dimitry Sibiryakov wrote: It can\t be reworked reliably - nobody can guarantee that DNS host name matches lanman name. Fortunately modern versions of gethostbyname() can resolve lanman names as well. Then reworking seems easy. Just preserve ISC_analyze_pclan() to extract

[Firebird-devel] WNET future

All, We had discussed in the past that supporting WNET does not make sense, as it has nearly zero advantages over TCP and pretty much nobody uses it nowadays. Could we please make a final decision about that? Should it be dropped in v5 or somewhat later? Or should it be preserved during a

Re: [Firebird-devel] Firebird and DSQL Scrollable Cursors

28.11.2021 14:47, Dimitry Sibiryakov wrote: RDB$DB_KEY for the current record as well. It's not a property of the cursor. Consider joins, unions, procedures, views, etc. Dmitry Firebird-Devel mailing list, web interface at https://lists.sourceforge.net/lists/listinfo/firebird-devel

Re: [Firebird-devel] Firebird and DSQL Scrollable Cursors

27.11.2021 15:04, Dimitry Sibiryakov wrote: I would consider adding a NO_BATCH flag (which is currently triggered using FOR UPDATE syntax) to cursorFlags. That would be useful in some cases. And if statements with "WHERE CURRENT OF" condition also were somehow marked client libraries could

Re: [Firebird-devel] Firebird and DSQL Scrollable Cursors

28.11.2021 14:37, Dimitry Sibiryakov wrote: And it doesn't need to be a dedicated method of IResultSet. Something generic and easily extendable like IResultSet::getInfo() would be enough. Then we may support both "current position" and "total row count" in getInfo(), letting the client

Re: [Firebird-devel] Firebird and DSQL Scrollable Cursors

28.11.2021 14:02, Mark Rotteveel wrote: Is there a way to determine at which row the cursor is currently positioned? JDBC has the ResultSet.getRow()[1] method which is documented as: "Retrieves the current row number. The first row is number 1, the second number 2, and so on." This is not

Re: [Firebird-devel] Firebird and DSQL Scrollable Cursors

28.11.2021 13:11, Mark Rotteveel wrote: In other words, it looks as if Firebird when asked for 4 rows, will return 4 rows and *also* buffer 4 more *on the server*, and return those unconditionally on the next fetch. Looks right, although weird I didn't notice that during the testing. To be

Re: [Firebird-devel] Firebird and DSQL Scrollable Cursors

27.11.2021 17:28, Mark Rotteveel wrote: I'm running into some odd behaviour. As soon as I do a fetch_next or fetch_prior, any subsequent fetch ignores the fetch direction, and applies fetch_next (or fetch_prior). Correction: it behaves as fetch_next (or fetch_prior) for the amount of rows

Re: [Firebird-devel] Firebird and DSQL Scrollable Cursors

27.11.2021 12:42, Mark Rotteveel wrote: Yes, I think that is perfectly acceptable for an initial version. Scrollable cursors are a bit of an oddity anyway, but having scrollable cursors in embedded access, but not in remote access is IMHO less acceptable than bad performance. As long as the

Re: [Firebird-devel] Firebird 5 and Update...Returning

26.11.2021 17:47, Tony Whyman wrote: 3. IBX tries to be general purpose and so prepares a statement, then checks the statement type, and then calls the appropriate IStatement method. Then it shouldn't be broken. It gets isc_info_sql_stmt_select, calls openCursor() and everything works as

Re: [Firebird-devel] Firebird 5 and Update...Returning

26.11.2021 17:28, Tony Whyman wrote: 1. IAttachment.prepare is used to parse 'Update Employee Set Hire_Date = ? Where EMP_NO = ? Returning LAST_NAME' 2. IStatement.getType is then used to determine the statement type. OK so far. 3. Prior to calling IStatement.Execute, the statement type is

Re: [Firebird-devel] Firebird and DSQL Scrollable Cursors

26.11.2021 14:51, Tony Whyman wrote: Just compiled the updated master branch and tested with IBX. All looks good with the test suite returning the same set of results for bot remote and local databases. Many thanks for the good work. And my thanks to you for testing ;-) I've noticed that

Re: [Firebird-devel] Firebird and DSQL Scrollable Cursors

Mark et al, Yes, I think that is perfectly acceptable for an initial version. Scrollable cursors are a bit of an oddity anyway, but having scrollable cursors in embedded access, but not in remote access is IMHO less acceptable than bad performance. As long as the performance behaviour is

Re: [Firebird-devel] Request IDs, MON$STATEMENTS and MON$STATEMENT_ID

09.11.2021 03:21, Adriano dos Santos Fernandes wrote: I think all statements should be split in MON$STATEMENTS and MON$COMPILED_STATEMENTS. What about execute_immediate? Should they be reported only inside MON$STATEMENTS or also have a record in MON$COMPILED_STATEMENTS but as not shareable

Re: [Firebird-devel] ON DISCONNECT triggers and MON$ATTACHMENTS

09.11.2021 12:00, Alex Peshkoff wrote: Currently ON DISCONNECT triggers are not called when an attachment is deleted from MON$ATTACHMENTS by another attachment. Is it the correct behavior? On my mind - not. The only case when ON DISCONNECT triggers not to be called is server shutdown.

Re: [Firebird-devel] Request IDs, MON$STATEMENTS and MON$STATEMENT_ID

08.11.2021 19:54, Adriano dos Santos Fernandes wrote: In this case I think we better sooner introduce MON$COMPILED_STATEMENTS with some duplicate information already present in MON$STATEMENTS, Obviously, SQL text and plan belong to the statement. The rest looks request-specific (timestamp

Re: [Firebird-devel] Request IDs, MON$STATEMENTS and MON$STATEMENT_ID

08.11.2021 17:54, Dimitry Sibiryakov wrote: Nope, I believe the new ID must be generated also by findRequest() if the clone was found in the cache. Will it make impossible to detect repeatable execution of a prepared statement as opposite for execution of a new one every time?

Re: [Firebird-devel] Request IDs, MON$STATEMENTS and MON$STATEMENT_ID

08.11.2021 16:50, Adriano dos Santos Fernandes wrote: Despite its name, what MON$STATEMENTS show are requests (not statements). True, but statement/request separation didn't exist when MON$STATEMENTS was implemented ;-) And end users deal with statements, they have no idea what "request"

Re: [Firebird-devel] Plans for 3.0.8

06.11.2021 10:30, Omacht András wrote: it's November now. Any chance of coming out in the near future? 3.0.7 was released October 20, 2020. I'm going to tag the tree tomorrow. The release will come shortly after. Dmitry Firebird-Devel mailing list, web interface at

Re: [Firebird-devel] Cascade replication

27.10.2021 14:52, Pro Turm wrote: Is it possible and how does a replica become primary at some point? It never does it by itself. Firebird provides replication, but high-availability cluster (which you're talking about) is way more than just replication. Custom automatization is required.

Re: [Firebird-devel] Firebird and DSQL Scrollable Cursors

23.10.2021 17:13, Mark Rotteveel wrote: If record buffering is hard, it could have been done **without** it. Then it would have been the choice of the user whether it is worth the performance implications or not. So you consider acceptable that forward-only usage of scrollable cursors is

Re: [Firebird-devel] Cascade replication

27.10.2021 09:06, Karol Bieniaszewski wrote: Can you point me https://github.com/FirebirdSQL/firebird/commit/e6a33454e871b9f9a368ccf281081e867c2b18cf what is enabled here and on which side? If i

Re: [Firebird-devel] Tablespaces proposal

12.10.2021 18:26, Dimitry Sibiryakov wrote: System tables are operated in system transaction They're modified in user transaction(s). Dmitry Firebird-Devel mailing list, web interface at https://lists.sourceforge.net/lists/listinfo/firebird-devel

Re: [Firebird-devel] Partitioning (was: Tablespaces proposal)

12.10.2021 16:21, Dimitry Sibiryakov wrote:   INSERT:   Nothing except time wasting to calculation partitioning key and creation of a new partition if necessary (ignorable). Slightly faster inserts into indices.   UPDATE:   DELETE: Faster index GC after them.   BACKUP: Backup of

Re: [Firebird-devel] Tablespaces proposal

12.10.2021 15:26, Dimitry Sibiryakov wrote: In this case your vision of partitioning is quite special because in others' implementations it has nothing to do with multiple files Partition is a page set. Different page sets may be surely stored inside a single database file, but they may

Re: [Firebird-devel] Tablespaces proposal

12.10.2021 14:52, Dimitry Sibiryakov wrote: GOALS == 1) Extend the current limits on database size   Current limit is 16 TB and can be extended without explicit tablespace managing by something similar to OS memory mapping technique effectively adding some external-sourced bits to

Re: [Firebird-devel] Tablespaces proposal

12.10.2021 13:36, Kjell Rilbe wrote: Support for many page sizes requires changes in page cache management and should be considered together. I don't see it as "must have" feature, btw. That's the feature that our DB would benefit most from probably, since some tables are orders of

Re: [Firebird-devel] Tablespaces proposal

11.10.2021 22:22, Lucas Schatz wrote: Just to clarify, the use of tablespace will be optional, right? Sure. Dmitry Firebird-Devel mailing list, web interface at https://lists.sourceforge.net/lists/listinfo/firebird-devel

Re: [Firebird-devel] Charset of replicated SQL

11.10.2021 18:11, Dimitry Sibiryakov wrote: In which case charset received by IReplTransaction::executeSqlIntl() can be different from charset of attachment received by IReplicatedSession::init()? Ideally, never. I can imagine only the case of cascade replication when the Applier hacks

Re: [Firebird-devel] Tablespaces proposal

11.10.2021 18:41, Vlad Khorsun wrote: 2. *ALTER TABLESPACE FILE '/path/to/file'*   In DDL, ALTER usually combined with ADD | SET | DROP, so let follow this convention. I.e. ALTER TABLESPACE SET FILE '/path/to/file' I'm not so sure about "usually", e.g. ALTER INDEX INACTIVE, ALTER DOMAIN

Re: [Firebird-devel] Firebird 4 Replicaton - INET/inet_error: read errno during replicaton

05.10.2021 09:44, Nils Bödeker пишет: Are there any plans when the next subrelease are published. Yes, during the next couple of months. Dmitry Firebird-Devel mailing list, web interface at https://lists.sourceforge.net/lists/listinfo/firebird-devel

Re: [Firebird-devel] Plans for 3.0.8?

06.09.2021 13:31, Omacht András wrote: is 3.0.8 expected to be released in the near future? Yes, September-October. Dmitry Firebird-Devel mailing list, web interface at https://lists.sourceforge.net/lists/listinfo/firebird-devel

Re: [Firebird-devel] Dialect 3 inconsistent round/trunc - configurable calculation method needed

02.09.2021 12:17, Mark Rotteveel wrote: I find the suggestion to make this configurable an interesting one, but this wouldn't fundamentally resolve the issue you have, it just would change the compound error of calculation. For example, we followed your suggestion and provide an option to use

Re: [Firebird-devel] Dialect 3 inconsistent round/trunc - configurable calculation method needed

31.08.2021 23:53, Mark Rotteveel wrote: The only debatable feature of dialect 3 division is the fact the calculation stops (equivalent to floor rounding), while reduction of scale through assignment or cast applies half-up rounding "Whether to round or truncate when performing division is

Re: [Firebird-devel] Dialect 3 inconsistent round/trunc - configurable calculation method needed

01.09.2021 09:29, Molnár Attila wrote: In dialect 3 you have to cast to double always for not to loose precision. I believe you may avoid the casts if you store everything as NUMERIC inside the db, but your procedures use DOUBLE (or better DECFLOAT) for inputs/outputs/locals. Dmitry

Re: [Firebird-devel] isc_info_sql_stmt_type/isc_info_sql_stmt_flags

19.08.2021 18:29, Dimitry Sibiryakov wrote: I'm not sure why the client application would need to know the statement type at all ;-) Distinguish DDL from DML and transaction control - quite useful if you accept SQL from outside of application. I mostly meant it's pointless to know the

Re: [Firebird-devel] isc_info_sql_stmt_type/isc_info_sql_stmt_flags

19.08.2021 17:30, Mark Rotteveel wrote: Since RETURNING was created, we change values of isc_info_sql_stmt_type so clients can understand that statements with RETURNING have values. With GH-6815, RETURNING will return cursors (except for INSERT INTO ... VALUES RETURNING which works as before).

Re: [Firebird-devel] File and table sizes in Firebird 4.0

14.08.2021 10:02, Mark Rotteveel пишет: Now I see you mentioned 32 TB as the database size limit. How was it calculated? It should be the same 128 TB, AFAIK. The 32 TB is the old value on the page, when the entire page was for Firebird 2.5. I have no idea who wrote the previous version of

Re: [Firebird-devel] File and table sizes in Firebird 4.0

13.08.2021 10:04, Mark Rotteveel wrote: I'd still like an answer to the following questions (assume page size 32KB for all): - What is the maximum file size of a Firebird 4 database Theoretically unlimited (depends on OS and filesystem). Practically, it cannot be bigger than 128 TB (2^32

Re: [Firebird-devel] Blobs and OCTET_LENGTH

07.08.2021 12:31, Mark Rotteveel wrote: Currently, for blobs that are 4GB or longer, OCTET_LENGTH will silently truncate the length. This means that a 4GB blob is reported as length 0, a 5GB blob as 1,073,741,824. It's not OCTET_LENGTH who's guilty, it's blob itself: In memory: ULONG

Re: [Firebird-devel] replication/Protocol.h

27.07.2021 17:32, Dimitry Sibiryakov wrote: isn't header defining replication protocol supposed to be public? Yes, it is. Please add a ticket. Dmitry Firebird-Devel mailing list, web interface at https://lists.sourceforge.net/lists/listinfo/firebird-devel

  1   2   3   4   5   6   7   8   9   10   >