Re: [Firebird-devel] Support for timed-zones datatypes

21.11.2017 17:55, Adriano dos Santos Fernandes wrote: Implementing TIME WITH TIME ZONE and TIMESTAMP WITH TIME ZONE datatypes as specified in the SQL standard is not a big problem. However, standard says that CURRENT_TIME / CURRENT_TIMESTAMP returns the timed-zone datatype. That causes two

Re: [Firebird-devel] isc_info_svc_timeout incompatibility between Interbase and Firebird

04.10.2017 17:48, Dimitry Sibiryakov wrote:   In Interbase isc_info_svc_timeout is used like this: *spb++ = isc_info_svc_timeout; ADD_SPB_NUMERIC(spb, 60); /* 1 minute timeout */   In Firebird it is used like this: *p++ = isc_info_svc_timeout; ADD_SPB_LENGTH(p, 4); ADD_SPB_NUMERIC(p,

Re: [Firebird-devel] Default port on client side

27.09.2017 16:05, Roman Simakov wrote: I noticed that client uses RemoteServicePort parameter from firebird.conf if it's not specified in connection string. Is it by design? Yes, IIRC since Interbase times. Dmitry

[Firebird-devel] [FB-Tracker] Created: (CORE-5611) Higher memory consumption for prepared statements in FB3

Components: Engine Affects Versions: 4.0 Alpha 1, 3.0.2, 3.0.1, 3.0.0, 4.0 Initial Reporter: Dmitry Yemanov Customer has reported about noticably higher memory consumption with FB 3.0 than they see with FB 2.5. This is somewhat expected, given the metadata cache is per-attachment in FB3

Re: [Firebird-devel] Lateral derived tables

08.09.2017 16:55, Mark Rotteveel wrote: %type table_primary table_primary : table_proc | derived_table | '(' joined_table ')' ; IMHO, it wouldn't look logical to support LATERAL for "table_proc" but disallow it for "joined table". But LATERAL **is** a table_primary, it

Re: [Firebird-devel] Lateral derived tables

08.09.2017 15:31, Mark Rotteveel wrote: Isn't this all contained in the SQL specification? Reading the spec may differ. And we don't follow the standard strictly sometimes. 3) LATERAL was historically implied for joined stored procedures, e.g. I suggest 3b 4) LATERAL in nested

[Firebird-devel] Lateral derived tables (was: Plans to support cross and outer apply)

All, The key point of this standard feature is to allow sub-queries to reference priorly defined contexts (in joins). While thinking about this, I have a few questions to raise here. The standard defines LATERAL for derived tables only. This sounds logical but there are some corner cases to

Re: [Firebird-devel] Firebird 3, stored procs and plans

25.08.2017 13:06, Paul Reeves wrote: Is there a simple hack I could do to build FB3.0 with the plan enabled for SPs? Not so simple, as the code was completely refactored. I will try to provide you with a patch during the next days. But whatever happened to the SP debugger? AFAIK, it was

Re: [Firebird-devel] Firebird 3, stored procs and plans

25.08.2017 11:38, Paul Reeves wrote: In FB 3.0 the plan output for stored procs is always PLAN (NATURAL) whereas with FB 2.5 the plan for each sql statement to be executed within the SP are returned. Not having the plan available in FB 3.0 makes it quite difficult to see what is actually

Re: [Firebird-devel] Firebird 4.0 Alpha 1 release is available for testing

24.08.2017 23:34, livius wrote: However i see that context limit is "the same" for the single query Is this really plan for Firebird4 or it is postponed? It will be removed in the next Alpha/Beta release. Dmitry --

Re: [Firebird-devel] block size exceeds implementation restriction at JStatement::openCursor

Post a tracker entry to have it fixed. Or create an index for joining.Dmitry18:35, 24 августа 2017 г., "Jiří Činčura" : What is the plan? I suspect some hardcoded limit for the hash join  algorithm has been reached. Do you see HASH in the plan?Here's the plan:PLAN HASH (EMTD

Re: [Firebird-devel] block size exceeds implementation restriction at JStatement::openCursor

24.08.2017 17:50, Jiří Činčura wrote: I have a query that on one particular database throws: 2017-08-24T16:29:11.5140 (2704:01620040) ERROR AT JStatement::openCursor I:\DOWNLOADS\BI2.FDB (ATT_16, SYSDBA:NONE, NONE, TCPv6:::1/51084)

[Firebird-devel] Firebird 4.0 Alpha 1 release is available for testing

://www.firebirdsql.org/en/firebird-4-0-0-alpha1/ Release Notes: http://web.firebirdsql.org/downloads/prerelease/v40alpha1/Firebird-4.0.0_Alpha1-ReleaseNotes.pdf -- Dmitry Yemanov -- Check out the vibrant tech community

Re: [Firebird-devel] 3.0.2 consistent crash

19.08.2017 16:06, Jiří Činčura wrote: Running it (3.0.3.32798) for about an hour now. So far so good. Sounds good ;) So far it survived Friday night (usually a busy day in entertainment business), waiting for Saturday night. Fingers crossed. Quite scary to run on random snapshot build on

Re: [Firebird-devel] Alpha tag and mandatory features

16.08.2017 16:51, Dimitry Sibiryakov wrote: I see that Alpha tag is already set but I cannot find in master any mention of replication (neither in docs nor in sources), which was supposed to be a mandatory feature and thus available for at least preview in Alpha version. Some mandatory

Re: [Firebird-devel] Release build vs snapshot build

15.08.2017 14:30, Gabor Boros wrote: If an important bug fixed between releases, no other choice than switch to a snapshot. But I am not too brave to use a snapshot in production because built with different compiler than the release build. Or not? For example msvc*.dll files are different

Re: [Firebird-devel] Changing numerics scale

10.08.2017 21:57, Carlos H. Cantu wrote: DY> e.g. 1234567890.1234 is a valid (15, 4) but cannot be converted to (15, 6). Are you sure? I can store such value both in (15, 4) as well in (15, 6). Formally, it cannot be stored inside (15, 6). But historically, FB ignores the declared precision

Re: [Firebird-devel] Changing numerics scale

10.08.2017 20:29, Carlos H. Cantu wrote: Can someone explain why I can't change a field from numeric (15,4) to numeric (15,6) [error is "New scale specified for column TESTE must be at most 4."], but can change it to numeric (17,6) ? Because (15, 6) provides less integral precision (9 digits

Re: [Firebird-devel] HASH function (CORE-4436)

19.07.2017 17:44, Leyne, Sean wrote: Why do we need to extend the current function? Why not create separate, built-in, functions for each hash type with names* that align with the common algorithm name? MD2() ... MD5() SHA0() SHA1() SHA_224() ... SHA512_256() ... SHA3_224() ... SHA3_512()

Re: [Firebird-devel] HASH function (CORE-4436)

19.07.2017 01:32, Adriano dos Santos Fernandes wrote: Algorithm name could define result length. Yes, for constants. We need to decide whether the algorithm name can be passed dynamically (and thus be presented as "value" in the grammar) or must be predefined (via a string literal or

Re: [Firebird-devel] HASH function (CORE-4436)

18.07.2017 22:00, Leyne, Sean wrote: Would this approach have any performance advantages over using UDFs? People hate writing UDFs for common tasks. And IMHO getting a robust hash belongs to this category. Dmitry

Re: [Firebird-devel] HASH function (CORE-4436)

18.07.2017 21:55, Adriano dos Santos Fernandes wrote: We have HASH function that returns a 64 bit integer. The algorithm is bad and the result too small for a hash. Yes, and we have CORE-4436 with related complains. I propose to extend the same function with a second parameter with the

Re: [Firebird-devel] Removal of whitespace in changelog and readme

17.07.2017 10:48, Mark Rotteveel wrote: I just came across this commit by Adriano: https://github.com/FirebirdSQL/firebird/commit/c2584cf84be78f4aa157f003445dd17c8bc52c3f It removes a number of double-whitespaces in the CHANGELOG.md and README.md. Double whitespace at the end of a line

Re: [Firebird-devel] Detecting connection is using wire encryption

16.07.2017 13:31, Mark Rotteveel wrote: That said, I would still like to know if there is a specific info item I can use as well. There's no such an item, AFAIK. Dmitry -- Check out the vibrant tech community on

Re: [Firebird-devel] PORT_symmetric

14.07.2017 04:36, Adriano dos Santos Fernandes wrote: When client and server "architecture" are identical, remote code set PORT_symmetric flag and that causes some optimizations. That happened in the past. Asymmetric mode is unconditionally used since v1.5, in order to optimize bandwidth

Re: [Firebird-devel] Result set from where afield = afield

10.07.2017 15:11, Paul Reeves wrote: I've also seen, in stored procedures, this sort of construct... where (( e.EMP_NO = :AEMP_NO ) OR ( :AEMP_NO IS NULL)) which, if the input parameter AEMP_NO is NULL will also behave as if a full result set was requested. ie, the stored procedure will

Re: [Firebird-devel] Optimisation of where afield = coalesce(value1, value2 )

10.07.2017 14:20, Paul Reeves wrote: I can understand that this plan might appear to be invalid from the perspective of the optimiser. But surely the whole point of adding the PLAN clause is because I think I know better than the optimiser what I want. Unless the engine physically cannot

Re: [Firebird-devel] Optimisation of where afield = coalesce(value1, value2 )

10.07.2017 12:17, Paul Reeves пишет: On Fri, 7 Jul 2017 18:07:55 +0300 Dmitry Yemanov wrote 07.07.2017 17:51, Paul Reeves wrote: I understand that evaluating COALESCE(?, e.emp_no ) at prepare time may require a circular logic and is thus impractical It cannot be done at runtime either

Re: [Firebird-devel] Optimisation of where afield = coalesce(value1, value2 )

07.07.2017 18:26, Adriano dos Santos Fernandes wrote: BTW, isn't ConditionalStream used for something in this field? Yep, but the optimizer so far handles just one specific case (A = ? or ? is null). It could be extended though. Dmitry

Re: [Firebird-devel] Optimisation of where afield = coalesce(value1, value2 )

07.07.2017 18:12, Dimitry Sibiryakov wrote: In this particular case it is enough to know parameter value to choose plan. Parameters are known before reading table. True, but our optimizer is developed for generic cases, not such specific ones. It could be improved, but I'd say we have more

Re: [Firebird-devel] Optimisation of where afield = coalesce(value1, value2 )

07.07.2017 17:51, Paul Reeves wrote: But that doesn't answer all my questions... Given where e.EMP_NO = COALESCE(?, e.emp_no ) and that there is an index on EMP_NO, why doesn't the optimiser default to the index. After all, it is logically more likely that a value will be passed in the

Re: [Firebird-devel] 6 Month ago, SQL:2016 was released , a more detailed write-up

15.06.2017 20:28, marius adrian popa wrote: 6 Month ago, SQL:2016 was released, a more detailed write-up http://modern-sql.com/blog/2017-06/whats-new-in-sql-2016 Glad to know that DECFLOAT is now standard ;-) Dmitry

Re: [Firebird-devel] Effect of DST on current_timestamp values

13.06.2017 11:12, Leyne, Sean wrote: A post to the Firebird support list pointed out that current_timestamp values do not correctly reflect the effect of DST time changes while the server is running. In order for current_timestamp to reflect the correct local time values, the server needs to

[Firebird-devel] [FB-Tracker] Created: (CORE-5567) Direct system table modifications are not completely prohibited

Components: Engine Affects Versions: 3.0.2, 3.0.1, 3.0.0, 4.0 Initial Reporter: Dmitry Yemanov SQL> create database '/work/data/systab.fdb'; SQL> create domain my_type numeric(18, 2); SQL> commit; SQL> show domain MY_TYPE; MY_TYPE N

[Firebird-devel] [FB-Tracker] Created: (CORE-5566) Server crashes while restoring backup if the shadow file already exists

Type: Bug Components: Engine Reporter: Dmitry Yemanov gbak -c -rep C:\TEMP\TEST.FBK C:\TEMP\TEST.FDB Database is configured to have a shadow at C:\TEMP\CITYCARD.SHD. If there's no such a file, restore succeeds. If the file exists, expected error is reported: gbak: ERROR:I

Re: [Firebird-devel] Windows snapshots are outdated

06.06.2017 09:32, Gabor Boros wrote: The latest 3.0/4.0 kits have 2017-05-24 date. VM has some troubles, we're working on that. Dmitry -- Check out the vibrant tech community on one of the world's most engaging

Re: [Firebird-devel] SUPERSERVER_V2

25.05.2017 18:53, Adriano dos Santos Fernandes wrote: What's SUPERSERVER_V2 in the code? Old attempt by Borland to implement some features that can be utilized by a properly threaded SuperServer. Will it be used some day? Will it be removed some day? We preserve it as a reference. Some

Re: [Firebird-devel] Under what condition can RDB$RELATION_TYPE be NULL?

16.05.2017 22:27, Mark Rotteveel wrote: > > But it does hurt if you have a condition: "where rdb$relation_type = 0" > (or in this case: "where rdb$relation_type in (0, 3)"; shouldn't the > restore fix this up and make NULL explicit 0? Historically, many system fields inherit this behaviour and

Re: [Firebird-devel] Under what condition can RDB$RELATION_TYPE be NULL?

17.05.2017 01:02, Leyne, Sean wrote: > > gbak is not a special process, it is restricted the same as user connections, > so with v3+ it would not be able to execute any DML operations on system > tables. gbak is a special process and it does work with system tables directly. Dmitry

Re: [Firebird-devel] Under what condition can RDB$RELATION_TYPE be NULL?

16.05.2017 22:14, Mark Rotteveel wrote: > A bug was just reported for Jaybird 3 > (http://tracker.firebirdsql.org/browse/JDBC-494); I made changes to use > RDB$RELATION_TYPE to discriminate between the different relation types, > but apparently it can be null under some conditions. > > What are

Re: [Firebird-devel] Start transaction from base transaction

05.05.2017 20:01, Vlad Khorsun wrote: > > %typesnap_shot > snap_shot > : SNAPSHOT > | SNAPSHOT TABLE > | SNAPSHOT TABLE STABILITY > + | SNAPSHOT SHARING FROM SNAPSHOT BASED ON ? Dmitry

Re: [Firebird-devel] Changing IRoutineMetadata in Plugin::makeProcedure

18.04.2017 17:40, Jiří Činčura wrote: > > Also going from SQL_TEXT to SQL_VARYING should be possible, right? Generally it is, unless SQL_TEXT is of length 32766 or 32767. Dmitry -- Check out the vibrant tech community

Re: [Firebird-devel] MON$Attachment fields vs. RDB$Get_Context("SYSTEM", ....)

04.04.2017 16:30, Leyne, Sean wrote: > > BTW, why would they have names which are different from the names already > established in the MON$ table? > >>> - MON$REMOTE_PID >>> - MON$REMOTE_PROCESS Because the naming mismatch exists since the very beginning (CLIENT_ADDRESS /

Re: [Firebird-devel] MON$Attachment fields vs. RDB$Get_Context("SYSTEM", ....)

31.03.2017 01:11, Leyne, Sean wrote: > > One of my developers was looking for a simple way to determine what > Process was the current DB operation related to. > > I knew that MON$Attachments has a MON$Remote_Process value, so I > expected the same details would be available thru >

Re: [Firebird-devel] [FB-Tracker] Created: (CORE-5507) Wrong value of the new field at the old records, created before that new field was added.

24.03.2017 09:33, Vlad Khorsun wrote: > >> Firebird is known to upgrade the record format while reading. "Upgrade" >> here means using the latest (aka current) format. The current format is >> the one that can be seen in RDB$RELATION_FIELDS. So one may expect that >> the default value to be used

Re: [Firebird-devel] [FB-Tracker] Created: (CORE-5507) Wrong value of the new field at the old records, created before that new field was added.

24.03.2017 02:29, Mark Rotteveel wrote: > To me the behavior described under "actual" intuitively sounds like the > correct behavior. Why do you expect that the column value would change > to 'ABC'? This is really a tricky case. The "replace non-existing value with the default one" hack is a

Re: [Firebird-devel] Where is Android port?

23.03.2017 05:19, Carlos H. Cantu wrote: > I see two mentions in the 3.02 ReleaseNotes about Android port > [(CORE-3885) and (CORE-5332)], but I can't find any Android link in > the download page. > > This needs to be fixed. To be published, I'd want it to be rebuilt from the 3.0.2 codebase. The

Re: [Firebird-devel] NBAK simplification RFC

20.03.2017 20:06, Dmitry Yemanov wrote: > > Agreed. But I'm really worried about taking locks in ASTs, this sounds > as a dangerous practice to me. I smell new deadlocks. Just to clarify: I meant taking LM locks here. It could be safer for low-level locks.

Re: [Firebird-devel] NBAK simplification RFC

20.03.2017 19:43, Vlad Khorsun wrote: > >> Firebird doesn't use signals for AST delivery for a long time already >> and it might be possible to issue new locks from inside AST handler. >> >> Therefore it might make sense to go back to this logic. This would make >> nbackup state locks very

Re: [Firebird-devel] windows test build - least painful way?

28.02.2017 17:18, Michal Kubecek wrote: > > The problem is the series also touches windows specific code (including > WNET and XNET) BTW, you may wipe out WNET at all. We seemed to have an agreement on that. Dmitry --

Re: [Firebird-devel] [FB-Tracker] Created: (CORE-5493) Add context variable about transaction start timestamp

01.03.2017 19:50, Vlad Khorsun wrote: > >>> If this variable is added as a context variable into "SYSTEM" namespace, >>> simple >>> "START_TIMESTAMP" should be enough >> >> It could be confused with attachment-start timestamp. > > I thought it is clear that ticket is about new system contex

Re: [Firebird-devel] [FB-Tracker] Created: (CORE-5493) Add context variable about transaction start timestamp

01.03.2017 19:33, Dimitry Sibiryakov wrote: > If this variable is added as a context variable into "SYSTEM" namespace, > simple > "START_TIMESTAMP" should be enough It could be confused with attachment-start timestamp. Dmitry

Re: [Firebird-devel] windows test build - least painful way?

28.02.2017 17:18, Michal Kubecek wrote: > > as my Hackweek project, I played with struct rem_port and tried to turn > it into class hierarchy with virtual functions. The plan is to use this > to implement listening on multiple sockets (CORE-5219) and possibly also > AF_UNIX socket support but I

Re: [Firebird-devel] Firebird friendly error messages

01.03.2017 00:18, Dmitry Kuzmenko wrote: > > As to BLR, I don't think that eliminating BLR is a good idea. You need > to have same or better speed of interpreting SQL Execution time does not depend on whether it's BLR or SQL. Parsing time (read: prepare time) depends. Dmitry

Re: [Firebird-devel] RFC: Timeouts

25.02.2017 17:21, Adriano dos Santos Fernandes wrote: > > But, client side already can set it own timer and cancel the statement. It was considered. However, it would mean that our implementation is completely useless for Java and .NET clients, they would have to implement timeouts from

Re: [Firebird-devel] RFC: Timeouts

25.02.2017 12:37, Mark Rotteveel wrote: >> Do you/anyone know if these engines return full results sets or follow the >> "page set" approach? > > As far as I know Oracle[1], PostgreSQL[2], SQL Server[3] support it. I > believe MySQL does as well. Don't know about other database systems, but > I

Re: [Firebird-devel] RFC: Timeouts

All, Let me jump into discussion and share my own concerns. Depending on the plan, statement may take 99% of its "working" time inside execute() or inside fetch() or that time could be distributed among the API calls. Neither client nor DBA has any control on that. So I consider seriously

Re: [Firebird-devel] RFC: Timeouts

25.02.2017 03:55, Leyne, Sean wrote: > > it is the value that represent a direct CPU cost of a SQL statement. You actually seem wanting CPU quotas. But they're not timeouts. A long-running statement may produce almost zero CPU load. Dmitry

[Firebird-devel] [FB-Tracker] Created: (CORE-5481) Available indices are not used in some cases if ORDER BY expression is a filtered one

: Firebird Core Issue Type: Bug Components: Engine Affects Versions: 3.0.1, 3.0.0, 4.0 Initial Reporter: Dmitry Yemanov CREATE TABLE ORG_ACCOUNTS ( ORGACCOUNTID BIGINT NOT NULL PRIMARY KEY ); CREATE TABLE BALANCES ( BALANCEID BIGINT NOT NULL

Re: [Firebird-devel] Deadlock parsing BLR

24.01.2017 12:22, Jiří Činčura wrote: > Anyone? It's hard to say anything without a test case. Dmitry -- Check out the vibrant tech community on one of the world's most engaging tech sites, SlashDot.org!

Re: [Firebird-devel] [FB-Tracker] Created: (CORE-5460) Insert NULL into identity column with auth generated value

19.01.2017 00:51, Ann Harrison wrote: > > In what universe does that make sense? The field is NOT NULL. You're > storing NULL in it. That's an error. I'd say it depends. What about a BEFORE trigger converting input NULL to something valid before storing? Dmitry

Re: [Firebird-devel] Virtual metadata

18.01.2017 12:38, Alex Peshkoff wrote: > > Currently with dfw we do have a lot of DDL errors raised at commit time > i.e. it's not a regression. True, but only because the actual work is performed during commit. If we claim that DDL changes are applied immediately, but error is thrown at

Re: [Firebird-devel] Virtual metadata

17.01.2017 14:28, Alex Peshkoff wrote: > >>> Returning to 'allow concurrent transactions to change the same objects'. >>> What if both transactions create same objects or any other phase 1 >>> conflict? >>> First committed wins? >> Yes. > > That's OK for me. I don't think I like it. With DML,

Re: [Firebird-devel] linux build failure - security.sql (bisected)

17.01.2017 16:13, Adriano dos Santos Fernandes wrote: >> It should be possible to add one or more alternative rules in the >> grammar where character set names are used in a way that preserves the >> backwards compatibility. > > I believe this is the thing we need to do. > > Just something as

Re: [Firebird-devel] Virtual metadata

17.01.2017 13:32, Dimitry Sibiryakov wrote: > > I always feel the same when I see special treating of system tables and system > transaction in VIO routines. Perhaps it's worth starting from deprecating DFW and only then come back to the metadata versioning? Dmitry

Re: [Firebird-devel] Virtual metadata

17.01.2017 13:18, Dimitry Sibiryakov wrote: > >> How does your idea address this? Between CREATE TABLE and INSERT page >> space (PP, IRP) must be allocated and initialized. And this cannot be >> reverted via the undo log in the case of rollback. > > It can. PP is bound to RDB$RELATIONS and IRP to

Re: [Firebird-devel] Virtual metadata

Yet another case: Transaction creates a new format, stores some records using this new format, then the server dies. After restart, changes in RDB$FORMATS/RDB$RELATIONS are occasionally backed out. Then it could be impossible to garbage collect the new record versions due to their format

Re: [Firebird-devel] Virtual metadata

16.01.2017 22:48, Dimitry Sibiryakov wrote: > >> But what about low-level logic like >> VIO_get_current() which must see uncommitted changes? > > If format is created at the end of DDL execution (instead of DFW), it > can/must be > written into database before any DML can write any record with

Re: [Firebird-devel] Virtual metadata

16.01.2017 23:08, Adriano dos Santos Fernandes wrote: > > DML changes in the same transaction uses real metadata, i.e., DDL being > changed does not affect DML or metadata cache. I.e. one cannot add a field and populate it with data within a single transaction. This sounds too much restrictive.

Re: [Firebird-devel] Virtual metadata

16.01.2017 23:39, Dimitry Sibiryakov wrote: > Then your schema won't solve problem with mixing DDL and DML. Users still > won't be able > to create table and fill it with data in one transaction. How does your idea address this? Between CREATE TABLE and INSERT page space (PP, IRP) must be

Re: [Firebird-devel] Virtual metadata

16.01.2017 22:04, Dimitry Sibiryakov wrote: > > Why "without gaps"? In my vision the first step is to modify garbage > collector/sweeper > to clean unused formats out. OK, it wasn't obvious from your message. >> How concurrent readers should access/skip physically stored records if >> their

Re: [Firebird-devel] Code style - right margin

16.01.2017 19:39, Alex Peshkoff wrote: > > With today 22-24" 16:9 screens 20" 4:3 is still enough for me ;-) Dmitry -- Check out the vibrant tech community on one of the world's most engaging tech sites, SlashDot.org!

Re: [Firebird-devel] Code style - right margin

15.01.2017 17:50, Adriano dos Santos Fernandes wrote: > What is our maximum code right margin? > > AFAIK it used to be 100 and I remember some discussion to increase it. > > Some people is thinking it's infinite. > > I think currently 100 is too low and 120 would be better. It used to be 80 and

Re: [Firebird-devel] Firebird 4 identifier limits

12.01.2017 18:00, Mark Rotteveel wrote: > > As far as I understand it is specifically for backwards compatibility > (eg tools that expect/depend on the max 31 characters **and** max 31 > bytes) limit Then IMO it should be a boolean, not a numeric limit. Dmitry

Re: [Firebird-devel] Firebird 4 identifier limits

12.01.2017 17:33, Leyne, Sean wrote: > > Why is a configuration setting for this required? > > This seems like a fix/complication for a problem that doesn't really exist. That was my opinion too. Dmitry -- Developer

Re: [Firebird-devel] Firebird 4 identifier limits

06.01.2017 17:53, Mark Rotteveel wrote: > I just noticed that in Firebird 4 the identifier length limits are > configurable. > > Is there a maximum length, or can I theoretically use a length of say > 8191 characters for an identifier? Maximum is 63 characters. IIRC, configuration allows to

Re: [Firebird-devel] Database initially shutdown after restore in FB4

06.01.2017 16:33, Mark Rotteveel wrote: > When restoring a database through the service API in FB4 (Windows 10 64 > bit, Firebird-4.0.0.487-0_x64), it looks like the database is initially > shutdown (or something else goes wrong during the attach). > > Is this intentional, or should I report a

[Firebird-devel] [FB-Tracker] Created: (CORE-5435) Badly selective index could be used for extra filtering even if selective index is used for sorting

-5435 Project: Firebird Core Issue Type: Bug Components: Engine Affects Versions: 3.0.1, 3.0.0, 4.0 Initial Reporter: Dmitry Yemanov It seems that Firebird 3 is sometimes choosing the index with less selectivity, which can have a serious effect

Re: [Firebird-devel] Firebird 4 features

04.01.2017 13:13, Dimitry Sibiryakov wrote: > > "This has the added benefit that tools can use this information to determine > the data > type consistently based on type and subtype". AFAIU, ticket suggests to match API's subtype also to field's subtype, in addition to matching it to the

Re: [Firebird-devel] Firebird 4 features

30.12.2016 18:05, Dimitry Sibiryakov wrote: > Do anybody object if I try to dig a little into CORE-5064? No, feel free. Dmitry -- Check out the vibrant tech community on one of the world's most engaging tech sites,

Re: [Firebird-devel] Wire protocol changes in Firebird 4?

30.12.2016 14:19, Dimitry Sibiryakov wrote: > > 1) Core team have no time for it. True. > 2) Core team have no time to review big patches from outsiders. Bullshit. > 3) Backward compatibility has to be kept. True. What a surprise! Dmitry

Re: [Firebird-devel] Deadlock parsing BLR

22.12.2016 10:55, Jiří Činčura wrote: > > On 2.5.6 I've got error %subj%. What is the exact error message? Dmitry -- Developer Access Program for Intel Xeon Phi Processors Access to Intel Xeon Phi processor-based

Re: [Firebird-devel] Windows snapshot builds broken?

18.12.2016 14:28, Mark Rotteveel wrote: > I just looked at the Windows snapshots builds, but they are a few days > off against the Linux builds, > > FB 4: Win: 2016-12-16, Linux: 2016-12-18 > FB 3: Win: 2016-12-12, Linux: 2016-12-18 > FB25: Win: 2016-12-13, Linux: 2016-12-18 > > Is there

[Firebird-devel] [FB-Tracker] Created: (CORE-5418) Inconsistent output when retrieving the server log via Services API

: Bug Components: Engine, SVCMGR Affects Versions: 2.5.6, 2.5.5, 2.5.4, 2.5.3 Update 1, 2.1.7, 2.5.3, 2.5.2 Update 1, 2.5.2, 2.5.1, 2.5.0 Environment: Consistently reproduced on Windows only Reporter: Dmitry Yemanov Priority: Minor When Services API

Re: [Firebird-devel] FB2.5.6 - '' = ' ' is evaluated as true

07.12.2016 16:24, Slavomir Skopalik wrote: > > is it correct that empty string '' in comparison with one space string ' > ' is evaluated as true? Yes. Accordingly to the SQL standard, trailing spaces are ignored in [most] comparisons. Dmitry

Re: [Firebird-devel] CORE-5099 build with gcc6 broken

03.12.2016 18:04, marius adrian popa wrote: > This can be closed > > CORE-5099 http://tracker.firebirdsql.org/browse/CORE-5099 > > master defaults to -std=c++11 > https://github.com/FirebirdSQL/firebird/search?utf8=%E2%9C%93=-std%3Dc%2B%2B11 > and gcc6 would be forced to compile in c++11 mode

Re: [Firebird-devel] Support for schemas/namespaces

13.11.2016 19:14, Fabiano Bonin wrote: > > Today I took a look at Firebird Planning Board, and didn't see a single > mention for schemas/namespaces in the plan. Planning board is about FB4 only. Schemas are likely to be implemented after that. Dmitry

Re: [Firebird-devel] [FirebirdSQL/firebird] 5aede1: Decimal floating point numbers - first draft

13.11.2016 19:18, Alex Peshkoff wrote: > > SQL> SELECT * FROM TESTDECFLOAT; > > FEE_DECFLOAT FEE_REAL PERCENTAGE > == > 0.70 0.6999 0.05 I do see the

Re: [Firebird-devel] [FirebirdSQL/firebird] 5aede1: Decimal floating point numbers - first draft

11.11.2016 18:26, Dimitry Sibiryakov wrote: >> - Added new datatypes: DECFLOAT(16) and DECFLOAT(34), using 64/128 bits >> for numbers representation. > > What is the point of these new types? Cannot you just expand list of back-end > storage > for standard DECIMAL? This is my concern too. What

[Firebird-devel] [FB-Tracker] Created: (CORE-5393) Bad optimization of some operations with views containing subqueries

: Bug Components: Engine Affects Versions: 3.0.1, 3.0.0, 4.0 Initial Reporter: Dmitry Yemanov Bug is caused by internally created derived expressions being based on all view streams, including streams burried inside subqueries, etc. This is causing various optimization

[Firebird-devel] [FB-Tracker] Reopened: (CORE-5382) Incorrect processing (truncation) of SQL statement with length 10MB+1

[ http://tracker.firebirdsql.org/browse/CORE-5382?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Dmitry Yemanov reopened CORE-5382: -- Sorry, Pavel was too fast to resolve this ticket. The current behaviour is intended, but honestly

Re: [Firebird-devel] Allowed C++11 feature

23.09.2016 02:27, Adriano dos Santos Fernandes wrote: > I would like to add the following well-supported C++11 feature to our > allowed list: > > Strongly-typed enum - > http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2007/n2347.pdf > > Comments? No objections. Dmitry

Re: [Firebird-devel] Necessity of prepare in FB3

22.09.2016 17:03, Dimitry Sibiryakov wrote: > > Why it can be ineffective? It is a client-side thing, no additional > round-trips is > required. Consider the embedded engine. Dmitry -- Firebird-Devel mailing list,

Re: [Firebird-devel] Necessity of prepare in FB3

22.09.2016 17:09, Alex Peshkoff wrote: > > Just one note - let's finish with batch API interface first. Looks like > required functionality may be present in that interfaces in much more > logical way. I'd say these features are orthogonal. I don't see why batch API calls should be used just to

Re: [Firebird-devel] Necessity of prepare in FB3

20.09.2016 17:02, Alex Peshkoff wrote: > > I just wantedto say that modifying behaviour of openCursor() > and letting IResultSetfetch from non-cursor object is hardly > correct solution. While this approach is surely not elegant (and suboptimal from the performance POV), I do see it as being

Re: [Firebird-devel] Necessity of prepare in FB3

22.09.2016 16:48, Dimitry Sibiryakov wrote: > >> So if there's a >> demand for such usage, I think we could allow that. > > It will make unnecessary the rest of API calls for statement execution. If someone wants absolutely unified but ineffective API - maybe yes. Other API calls are for those

Re: [Firebird-devel] CNCT_user and CNCT_host

16.09.2016 19:00, Jiří Činčura wrote: > > is the CNCT_user and CNCT_host visible for normal developer somewhere? I > suppose CNCT_user is overriden by isc_dpb_user_name, right? Similar with > CNCT_host and isc_dpb_host_name. CNCT_host = isc_dpb_host_name = MON$REMOTE_HOST CNCT_user =

Re: [Firebird-devel] C++11 features

01.09.2016 15:46, Adriano dos Santos Fernandes wrote: > > I see that before VC++ 2015 Update 3, it accepts everything supported > without compiler options, right? Looks so. > So, I think the plan should be: > > - Update Linux prefix files to include -std=c++11 > - Agree on a set of allowed

Re: [Firebird-devel] C++11 features

01.09.2016 14:04, Adriano dos Santos Fernandes wrote: > > MSVC10 supports nothing, and even MSVC12 is also a bit limited in regard > to MSVC14 and recent g++ and clang++: > > https://msdn.microsoft.com/en-us/library/hh567368.aspx We've agreed on MSVC13 for FBv4, so we cannot use features from

Re: [Firebird-devel] C++11 features

31.08.2016 11:06, Thomas Steinmaurer wrote: > > Do we know that the new language features are stable enough? So far we speak only about C++11 which is five years old already. And we won't know without trying anyway. I remember us discovering bugs in compilers during the C++ migration in early

<    1   2   3   4   5   6   7   8   9   10   >