Components: Engine
Affects Versions: 2.5.2 Update 1, 2.5.2, 2.5.1, 2.5.0, 3.0 Initial
Reporter: Dmitry Yemanov
Test case:
create table t (id int, d timestamp);
create index itd on t computed (cast(d as date));
select * from t
where cast(d as date) = current_date
[
http://tracker.firebirdsql.org/browse/CORE-2709?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Dmitry Yemanov reopened CORE-2709:
--
Fix Version/s: (was: 3.0 Alpha 1)
Rolled back from FB3 as well, due to the found
: Bug
Components: Engine
Affects Versions: 2.5.2 Update 1, 2.1.5 Update 1, 2.5.2, 2.1.5, 2.0.7,
2.5.1, 2.1.4, 2.5.0, 2.0.6, 3.0 Initial, 2.1.3, 2.1.2, 2.0.5, 2.1.1, 2.1.0
Reporter: Dmitry Yemanov
Priority: Minor
recreate table tab (col1 varchar(10), col2
10.04.2013 17:07, Stefan Heymann wrote:
I'm not sure if it is a good idea to have those per-database
configurations in one central place. So when you move a database to
another server you have to copy-and-paste those things to the other
server.
What about having a pair of files:
06.04.2013 13:42, Mark Rotteveel wrote:
The question is: if you don't have permissions for a column, are you
allowed to know of its existence?
I suppose the answer is yes. Simply because system tables are world
readable and this is unlikely to be changed in the foreseeable future.
Dmitry
All,
I'd like to propose some ways to convert DBKEY into a human-readable
form but still be able to quickly (without a full table scan) access the
record via its human-readable DBKEY.
Primarily, it could be used to report a unique id of the offending
record in error messages allowing users to
05.04.2013 10:54, Mark Rotteveel wrote:
Given the instability of DBKEY over multiple transactions, how useful is
this?
The more useful the closer we're to the source of problem to be
investigated using that DBKEY ;-) No absolute guarantee of course and
users should be aware of that.
Dmitry
05.04.2013 12:14, Dimitry Sibiryakov wrote:
AFAIK, DBKEY has type CHAR(X) CHARACTER SET OCTETS. CORE-3039 is closed with
resolution
won't fix. Obviously, there is no need for human readable form of such
fields.
Not for user fields, but DBKEY is somewhat special.
Unfortunately, DBKEY has
05.04.2013 12:27, Alex Peshkoff wrote:
But if we forget about hiding something from people - is not it useful
to change behavior of 'select *' in a case when some fields are not
selectable?
I don't mind, it just won't solve the problem being discussed here.
Dmitry
05.04.2013 13:07, Kjell Rilbe wrote:
But variable length for views?
DBKEY for views is a fake, it does not exist as a standalone physical
concept. So I ignore views in this thread, they're completely outside
the intended semantics of this proposal.
Dmitry
06.04.2013 1:24, Ann Harrison wrote:
DBKEY for views is a fake, it does not exist as a standalone physical
concept. So I ignore views in this thread, they're completely outside
the intended semantics of this proposal.
Perhaps the implementation has changed, but formerly the db_key of a row
04.04.2013 19:58, Leyne, Sean wrote:
So, the proposition is simple: add ability for engine to distinguish such
service fields and not include it into auto expanded list of fields for
table or
view at the queries above. I.e. service fields is fully accessible if
present in
query text
04.04.2013 19:41, Björn Reimer wrote:
Can't you realize this with removing select permission for a
column? Of course it's not yet possible as only update and reference
are allowed currently.
IIRC, the SQL spec declares select permissions for columns. And they're
surely intended to throw
04.04.2013 23:03, Roman Simakov wrote:
In RedDatabase we do not expand * in query select * from T into all
fields of T but only in fields which user can access.
IMO produce an error is incorrect in this case. User just want to see
all available fields.
Also IMO it can be a solution of
05.04.2013 5:53, Doug Chamberlin wrote:
Seems to me the leading solution would be to extend SQL compliance for
permissions on fields to the SELECT statement such that users would not
be able to SELECT fields for which they did not have permission.
Thinking twice, I see that it's not going to
26.03.2013 3:33, Thomas Beckmann wrote:
It seems to me we have a bug in nested joins:
Consider the statement below. It's supposed to show foreign key fields
which it does nicely with FB2.5. With 3.0 you'll get the error Column
unknown. RF.RDB$FIELD_NAME. At line 11, column 32. - this is the
26.03.2013 7:42, Dmitry Yemanov wrote:
This was an intended change which probably became an overkill. I will
report back after closer investigation.
Sorry, I thought that your issue was caused by the i.RDB$RELATION_NAME =
rf.RDB$RELATION_NAME condition, but it's not. So there's only one error
19.03.2013 9:54, Dmitry Kovalenko wrote:
Try to compile your right way with fourth level (/W4) compiler warnings :)
I've committed a solution that's expected to solve both issues.
Hopefully, it compiles on Linux :-)
Dmitry
19.03.2013 11:23, Alex Peshkoff wrote:
Was:
{TYPE_STRING, SecurityDatabase, (ConfigValue) $(root)/security3.fdb}
Correct:
{TYPE_STRING, SecurityDatabase, (ConfigValue) $(root)security3.fdb}
Yes, it's better
I respectfully disagree. The former string clearly distinguishes between
path and
Adriano,
I'll comment only the parts I have something to say.
- Character sets and plugins:
At some time in the past, Jim wanted to deprecate charsets and use just
UTF-8. I was opposite to this idea, and I probably still am, but it's a
fact that character sets and plugins are a difficult
Adriano,
External interfaces is my worry, not intl libraries.
Ah, I missed the point then.
Current we have things as:
const char* IMessageMetadata::getField(IStatus*)
This is not intl-safe, as engine would need to maintain per-attachment
buffers. I do not even know if this is ok
All,
We have switched from artificially stable datatypes (ISC_*) to native
ones in the new API. I have two related questions:
1) If we ever face a platform with sizeof(int) == 8 (IA64? anything
else?) would it be OK that our API becomes platform-specific in regard
to its ABI? Or was it
All,
I see only two choices good enough for considering:
a) Release 2.1.5.18497 and 2.5.2.26540 (suffixed with Security Update
1), don't mark it as a separate release but replace the binaries with
the new version (like we did for the bad builds in the past).
The question here is whether we
14.03.2013 11:48, Alex Peshkoff wrote:
I see no problems building packages with this patch. It's really
trivial, and if packages are based on previous tags (2.1.5/2.5.2), not
branches, they do not require QA and release notes, they can be released
with just single note: Fixed severe security
Adriano,
Log Message:
---
Change message buffers type to void*. It adds some casts, but avoid them
in users' code.
---
I disagree with this change. If we want to save users some casts, let's
change the public API but keep UCHAR* in lower levels, thus having extra
casts only in
28.01.2013 15:25, Alex Peshkoff wrote:
gbak: ERROR:action cancelled by trigger (3) to preserve data integrity
gbak: ERROR:table/procedure has non-SQL security class defined
gbak:Exiting before completion due to errors
What does the error signify?
Probably a bug. Can it be reproduced
24.01.2013 12:44, Alex Peshkoff wrote:
You did not understand Karol's answer. It does not matter how is
organized your application - as soon as firebird engine starting with
v.2.5 is embedded into it you can use execute statement to access
external datasources.
But not data sources that are
10.01.2013 18:24, Adriano dos Santos Fernandes wrote:
Previously, in-memory metadata was stored on the database, shared by
multiple (super) attachments.
Now it's in the attachment (att_triggers, att_functions, etc).
Is this temporary (to be adjusted in this version or in the next
09.01.2013 14:45, Mark Rotteveel wrote:
Where do you get this error?
It was Jira tracker, I suppose. Migration to the new repo is incomplete
there, AFAIR.
Dmitry
--
Master Java SE, Java EE, Eclipse, Spring,
10.01.2013 10:25, Alex Peshkoff wrote:
May be we should lock old SVN repository like it was done with CVS?
IMO, it should be disabled even for reading. The engine does not compile
there anyway, thus causing confusions.
Dmitry
08.01.2013 21:00, liviusliv...@poczta.onet.pl wrote:
I understand that i can get more reads becouse of small cache but why
writes?
Every read into a cache full of dirty pages (modified by sweep) implies
a page write, because the engine needs to reuse some page buffer for
reading.
Dmitry
All,
I'd like to get opinions whether the on disconnect triggers should be
fired in the cases when some connection is forcibly closed.
We have a number of cases that cause a more or less asynchronous
disconnection:
1) server shutdown
2) database shutdown
3) connection shutdown via monitoring
18.12.2012 21:04, Dimitry Sibiryakov wrote:
Checkout ok, but switch fails (after I replaced UUIDs by DE recipe):
svn: 'https://firebird.svn.sourceforge.net/svnroot/firebird/firebird/trunk'
is not the same repository as
'http://svn.code.sf.net/p/firebird/code'
Use svn relocate, not svn
16.12.2012 20:13, Vlad Khorsun wrote:
Also, it is not possible to relocate local working tree to the new URL, it
fails with error
The repository at
'svn://svn.code.sf.net/p/firebird/code/firebird/branches/B2_0_Release' has
uuid
'65644016-39b1-43b1-bf79-96bc8fe82c15', but the WC has
Type: Bug
Components: Engine
Affects Versions: 2.5.2, 2.1.5, 2.5.1, 2.1.4, 2.5.0, 3.0 Initial, 2.1.3,
2.1.2, 2.1.1, 2.1.0
Reporter: Dmitry Yemanov
Priority: Minor
If the query is interrupted while fetching from a large cursor and the client
decides
All,
Firebird v3 supports scrollable cursors in PSQL and I'm going to surface
them at the DSQL level as well. However, there's a question about how
they should be declared. In PSQL, this is done in the cursor
declaration, as per SQL spec:
DECLARE MY_CUR [SCROLL | NO SCROLL] CURSOR FOR (select
12.12.2012 17:43, Adriano dos Santos Fernandes wrote:
The SQL solution has more issues:
- No way to support scrollable EXECUTE BLOCK result (not sure if you
gonna to implement this, but is theoretically possible)
It's not covered by the current implementation and, speaking honestly,
I'd hate
06.12.2012 12:03, marius adrian popa wrote:
The generated the c++ code browser for the firebird database.
You can find it online here:
http://code.woboq.org/firebird/firebird
It is created using the Woboq Code Browser generator.
It focuses on improving the code navigation with proper
/browse/CORE-4004
Project: Firebird Core
Issue Type: Bug
Components: Engine
Affects Versions: 2.5.2, 2.1.5, 2.0.7, 2.5.1, 2.1.4, 2.5.0, 2.0.6, 3.0
Initial, 2.1.3, 2.1.2, 2.0.5, 2.1.1, 2.1.0
Reporter: Dmitry Yemanov
In fact, this ticket combines
Components: Engine
Affects Versions: 2.5.2, 2.1.5, 2.0.7, 2.5.1, 2.1.4, 2.5.0, 2.0.6, 3.0
Initial, 2.1.3, 2.1.2, 2.0.5, 2.1.1, 2.1.0
Reporter: Dmitry Yemanov
Priority: Minor
After performing a garbage collection pass, the sweep advances the global OIT
number
Issue Type: Bug
Components: Engine
Affects Versions: 2.5.2, 2.5.1, 2.5.0
Environment: The crash is Linux/UNIX specific, but the root of the
issue is platform independent.
Reporter: Dmitry Yemanov
The shutdown AST is delivered to the database with the already
20.11.2012 13:53, Frank Schlottmann-Gödde wrote:
I asked this in the support list, but got no answer:
First of all, what FB version are you talking about?
Dmitry
--
Monitor your physical, virtual and cloud
19.11.2012 19:54, Ann Harrison wrote:
On Sat, Nov 17, 2012 at 3:36 AM, Dmitry Yemanov firebi...@yandex.ru
mailto:firebi...@yandex.ru wrote:
gbak - fb_dump
nbackup - fb_backup
because IMO it better reflects their goals.
Gbak is not equivalent to the MySQL or Postgres dumps
17.11.2012 13:54, Philippe Makowski wrote:
I guess it depends on the keyboard layout, too.
yes, and we have fb_lock_print, fb_inet_server, fbsvcmgr, fbtracemgr,
fb_config, fbguard
Just a note. There's no fb_inet_server or fb_smp_server anymore. I don't
know anything about fb_config, is it
16.11.2012 23:38, Leyne, Sean wrote:
may be Firebird 3 is the good time frame to rename our binaries ?
for example :
fb_sql, fb_bak, fb_sec, fb_fix, fb_stat, fb_nbackup, fb_qli, fb_pre,
fb_split,
fb_qli
Basically, I agree with a new (and consistent) prefix. Personally, I'd
rather prefer
Issue Type: Bug
Components: Engine
Affects Versions: 2.5.2
Environment: Linux / MacOS 64-bit only
Reporter: Dmitry Yemanov
Log output example:
reservdb Sun Nov 11 02:26:56 2012
Sweep is started by SYSDBA
Database idx_test
OIT 855585, OAT 855586, OST
: Bug
Components: Engine
Affects Versions: 2.5.2
Reporter: Dmitry Yemanov
A part of the backtrace:
#1 pop (this=0x2aab64991a48, tdbb=0x2aab0897ea40, request=0x2aab60059bd0)
at
../src/dsql/../dsql/../dsql/../dsql/../jrd/../jrd/../jrd/../common/classes/stack.h:146
12.11.2012 16:52, vince.dug...@virginactive.co.za wrote:
When running under load (150+ busy connections) SuperClassic clearly
uses only one NUMA node (threads are spread across 16 cores), while
Classic is spread evenly across all 64 cores.
Weird, I'd expect them behaving the same way. Perhaps
09.11.2012 15:15, marius adrian popa wrote:
There are other ODS changes in 2.5.1 vs 2.5.2?
http://www.linkedin.com/groupItem?view=gid=1467097item=183106276type=membercommentID=103490293
At least what bugs were related to the changes
CORE-3675 and CORE-3853.
Dmitry
09.11.2012 18:20, Poul Dige wrote:
1. Will it be enough to rebuild indexes, or will it be necessary with a
complete backup/restore cycle?
Time to look at the release notes, heh? ;-) Rebuild is enough.
2. In case rebuild of indexes is enough, will it be necessary to rebuild
indexes for
01.11.2012 11:59, Mark Rotteveel wrote:
As far as I know the CAST behavior in dialect 3 conforms to the SQL
standards, while those in dialect 1 don't. I don't think that
non-conformance is a good reason to stick to Dialect 1.
It's not about CAST per se, it's about multiplication and division.
01.11.2012 11:43, marius adrian popa wrote:
And the quad is gone
Not really. What has gone is the quad specific arithmetics.
The data type itself remains and I doubt it can be wiped out completely,
as AFAIK sometimes it's used for blob IDs.
BTW, another data type that seems asking for a
01.11.2012 15:16, Carlos H. Cantu wrote:
If the problem is due to the way Borland implemented numeric/decimal
math in dialect 3, why not just fix it? (no idea about how difficult it
would be)
The proper solution is far not trivial to implement. An easier one will
break existing applications
01.11.2012 17:32, Dimitry Sibiryakov wrote:
Way to nowhere. No matter how long new datatype is, 1/3 won't be precise.
1/3 = 0 in dialect 3, IIRC. No precision problems at all.
Dmitry
--
Everyone hates slow websites.
01.11.2012 23:28, Nikolay Samofatov пишет:
I privately discussed this issue with Dmitry and would like to confirm here
that backing out the
patch indeed fixes the problem.
У вас проблеима вызвана сочетанием двух вещей. Патч для 3034
действительно блокирует доставку АСТов на время скана
31.10.2012 12:29, Thomas Steinmaurer wrote:
IMHO: Dropping dialect 1 and 2 should be done with Firebird 3. People
still depending on dialect 1 will then be stuck on Firebird 2.5 until they
migrate to dialect 3. I think that is a better option than keep dragging
support for legacy
31.10.2012 12:50, Thomas Steinmaurer wrote:
That said, I'm against the idea in general ;-)
Sorry, I had intended to write:
That said, I'm NOT against the idea in general
as it should obviously be wiped out sooner rather than later. But this
is exactly the case when my personal humble opinion
31.10.2012 13:12, Nando Dessena wrote:
Deprecating dialects in Fb3 will not hurt anyone but at the same time
deliver a message.
Then you can postpone the decision to wipe them in the next release or
later.
No objections here, it just doesn't resolve the original problem Adriano
is facing.
31.10.2012 13:15, Dimitry Sibiryakov wrote:
I wonder why you don't allow to use BIGINT in dialect 1...
It was an old (FB1.5 time) decision to avoid some new features in
Dialect 3, especially those that old clients may be not prepared to deal
with. However, I must admit that that rule was not
31.10.2012 14:17, Alex Peshkoff wrote:
what about having 2 32-bit fields in
ODS12? In ODS13 we will remove that hack
I don't think we can remove system fields at all, at least without
breaking an unknown number of applications. And requiring users to
decode the trigger type based on either
31.10.2012 14:29, Adriano dos Santos Fernandes wrote:
I'd prefer to hack on allowing BIGINT on dialect 1
So far it looks like a lesser evil.
Dmitry
--
Everyone hates slow websites. So do we.
Make your web apps
31.10.2012 14:51, Mark Rotteveel wrote:
But to the original problem: Why not just declare it as a NUMERIC(27,0),
as I believe that is the equivalent to BIGINT, or doesn't that apply to
dialect 1?
NUMERIC(18) is the maximum we can offer. And yes, it's different between
dialects 1 and 3. It's
31.10.2012 15:32, Thomas Steinmaurer wrote:
Management = Firebird Admin List?
Nope, I meant just another part of my responsibilities ;-)
Dmitry
--
Everyone hates slow websites. So do we.
Make your web apps faster
31.10.2012 14:36, Pavel Cisar wrote:
a) It's mostly about pre-IB 6.0 applications that were not adapted to
dialect 3 since then. How many such apps do you think it's still out
there? Up to 0.01% ?
b) All new applications since IB 6.0 / FB 1.0 are dialect 3
applications, with very very few
31.10.2012 17:42, marius adrian popa wrote:
I see that 3.0 is in feature freeze mode
No, it's not.
Dmitry
--
Everyone hates slow websites. So do we.
Make your web apps faster with AppDynamics
Download AppDynamics
Ann,
InterBase was developed on MicroVaxen which had a 64-bit integer
datatype. So from
V1, there was support for what was called QUAD. Contemporary Intel
and Motorola
processors did not support the type, so it was dropped for those versions.
Can we conclude that no client app existing
The Firebird Project team is happy to announce that the v2.5.2 release
candidate kits for Linux, Windows and Mac OS X platforms are ready for
testing.
Download page:
http://www.firebirdsql.org/en/firebird-2-5-2-rc1/
Enjoy the testing and please don't hesitate to report the found
regressions (if
-3924
URL: http://tracker.firebirdsql.org/browse/CORE-3924
Project: Firebird Core
Issue Type: Bug
Components: Engine
Affects Versions: 2.5.1, 3.0 Initial, 2.5.2
Reporter: Dmitry Yemanov
It cannot be reproduced in ISQL as it requires
30.08.2012 11:40, Tor Stenvaag wrote:
The IB ApiGuide.pdf states
isc_dsql_fetch() returns the second element of the status vector. Zero
indicates success.
The value 100 indicates that no more rows remain to be retrieved.
I can not find any reference to isc_dsql_fetch in Firebird 2.5
22.08.2012 19:35, Adriano dos Santos Fernandes wrote:
What about RDB$DB_VERSION?
Sorry, this is not good.
Better alternatives: RDB$DB_TRANSACTION, RDB$DB_TRANSACTION_ID,
Simply RDB$RECORD_VERSION? ;-)
RDB$TRANSACTION_ID...
We have a column in RDB$TRANSACTIONS named this way.
Dmitry
20.08.2012 21:54, Mark Rotteveel wrote:
I can't seem to connect to tracker.firebirdsql.org, does anybody else
have that problem?
It works for me.
Dmitry
--
Live Security Virtual Conference
Exclusive live event
13.08.2012 19:15, arnaud le roy wrote:
it's normal that only the indexes on one table is used during an inner
join ?
for exemple :
table a
ID = pk_index
DATE = index a_date = selectivity : 0.1
NAME = index a_name selectivity :0.1
table b :
REFIDA = fk_index
REFPRODUIT = index
08.08.2012 5:24, Claudio Valderrama C. wrote:
Hello, is it just me? In FB3, I get
8..\..\..\src\jrd\nbak.cpp(381): warning C4305: 'argument' : truncation
from 'Jrd::lck_owner_t' to 'bool'
The offending code is
GlobalRWLock endLock(tdbb, *database-dbb_permanent, LCK_backup_end,
17.07.2012 10:58, Alex Peshkoff wrote:
Renaming has both pluses (mentioned by you) and minuses (people, who do
not need per-DB config, but want to manage aliases, will find it as a
minimum strange).
Why strange? An alias is just a registered user-level name of the
*database*, so the new
17.07.2012 19:30, Adriano dos Santos Fernandes wrote:
AFAIR, currently, temporary strings cannot be passed
to Arg::Str because they disappear
-- commenting about v2.5, but I don't think there's much difference
I believe this is not the case, because all former ERR_string() calls
disappeared
16.07.2012 17:05, Alex Peshkoff wrote:
Looks like Dimitry wants to make it ignore database pathname.
If so, then this looks crappy, sorry.
Dmitry
--
Live Security Virtual Conference
Exclusive live event will cover
13.07.2012 0:14, Leyne, Sean wrote:
Bad example, I should have said that:
SELECT ... FROM ... WHERE ColumnA = COS( ColumnB)
Doesn't use an index when it should be able to, just as the engine is able to
use an index for this query
SELECT ... FROM ... WHERE ColumnA = ColumnB
12.07.2012 19:44, Paul Vinkenoog wrote:
So... have we implemented the DT and CTE features correctly?
I believe it has nothing to do with our implementation of DTs and CTEs.
Create a view with gen_id and and select that field thrice - you will
get the same result. And views are here for a few
12.07.2012 22:20, Adriano dos Santos Fernandes wrote:
It's easy to change them both to run correct.
What do you mean? I can think of two solutions:
1) Track the duplicate references at the parser level and then embed
hidden variables similarly to how it was done for COALESCE.
2) Create
09.07.2012 18:41, Vlad Khorsun wrote:
I think these ideas should not mix concepts of trace with debug and
profile. So for what it will be useful?
Trace *is* very useful for both debugging and profiling.
No objections here. Especially at the absence of better tools ;-)
Ask google for SQL
09.07.2012 23:52, Thomas Steinmaurer wrote:
Anyway, I think it would be useful to offer something like a caller id
in the procedure trace output, which basically is the statement id of
the calling DML statement. This way, we don't lose the context of a SP
call and it's higher-level DSQL
06.07.2012 11:45, Dimitry Sibiryakov wrote:
How about isc_create_database()? Should it follow the same rules?
Sure.
Shouldn't it be coupled with prohibiting declaration of charset for single
fields?
Currently nothing prevent (me) from creating database with default charset
NONE and set
06.07.2012 11:54, Mark Rotteveel wrote:
I am not sure I see why you would need to prohibit setting the
characterset of a specific field when requiring the default characterset to
be set. Could you explain the reasoning on that?
I believe his was referring to the default charset being set to
06.07.2012 12:20, Dimitry Sibiryakov wrote:
I have a script which creates my tables in my own just created database or
any existing
user-choosen database. Because I can't predict default character set of such
user
database, all fields in this script are created with explicit character set
02.07.2012 17:22, Thomas Steinmaurer wrote:
Is this expected when running a sweep not via gfix?
It's expected when tracing all attachments indirectly utilized by
services. You can see the same situation in the monitoring tables.
Dmitry
30.06.2012 0:02, Leyne, Sean wrote:
I would say make the Default 8K since that is the typical disk block size of
modern HDD.
I tend to agree.
Current HDDs are also an argument to make the minimum page size 4K, since
that is the physical sector size for the 2TB+ HDDs.
The minimum is 4K
27.06.2012 11:10, Thomas Steinmaurer wrote:
gstat output has been changed/extended in Firebird 3. Can somebody
comment on the new data returned by gstat? Or perhaps there is some
description available in SVN.
Tables:
Primary pointer page: 179, Index root page: 180
Same as before.
22.06.2012 20:04, Philippe Makowski wrote:
Error occurred during export before upgrade: Erreur d'exportation de données
: org.ofbiz.core.entity.GenericDataSourceException: SQL Exception while
executing the following:SELECT ID, issueid, VOTES, TIMESTAMP FROM
votehistory (GDS Exception.
21.06.2012 11:20, Alex Peshkoff wrote:
Both places. A lot of firebird.conf parameters can be used in aliases in
order to have different config per database.
Maybe we should think about renaming aliases.conf to something like
databases.conf to better reflect both its original (custom database
21.06.2012 12:15, Thomas Steinmaurer wrote:
While I appreciate this new feature, hopefully this doesn't additionally
delay the release of 2.5.2
It should not. The feature was field tested in the FB 2.5 codebase, so
the patch is available and it's not expected to cause any major harm at
the
21.06.2012 16:31, Adriano dos Santos Fernandes wrote:
It's sad that isc_segment and isc_segstr_eof are considered errors and
goes to status vector and not only returned by isc_get_segment,
different than isc_dsql_fetch and its 100 status.
I agree this is very confusing.
I don't consider
21.06.2012 17:08, Alex Peshkoff wrote:
Just one detail. Boolean type is treated slightly different in various
languages (specially TRUE value: 1, -1, any non-zero). Therefore let's
better use int as returned type in API.
Then we should fix IParametersMetadata::isNullable and
URL: http://tracker.firebirdsql.org/browse/CORE-3873
Project: Firebird Core
Issue Type: Bug
Components: Engine
Affects Versions: 2.5.1, 2.5.0, 3.0 Initial
Reporter: Dmitry Yemanov
There is no active attachment at this moment, but some code
The Firebird Project team is happy to announce that the v2.1.5 release
candidate kits for Linux, Windows and Mac OS X platforms are ready for
testing.
The download page:
http://www.firebirdsql.org/en/firebird-2-1-5-rc1/
Enjoy the testing and please don't hesitate to report the found
regressions
11.05.2012 15:54, Thomas Steinmaurer wrote:
as there is a way to define a temporary page buffers (cache) value at
attachment-level, I think it might be reasonable to add MON$PAGE_BUFFERS
(or whatever it is called then) in MON$ATTACHMENTS?
Sounds reasonable. But what should it contain for
21.04.2012 12:55, Dimitry Sibiryakov wrote:
I've got an idea: what if to apply DISTINCT (and may be GROUP BY) filter to
intermediate results of phase 1 and 3.
I'm not sure what you have in mind, but duplicates are rejected at the
early steps of sorting.
Dmitry
21.04.2012 15:26, Dimitry Sibiryakov wrote:
That's exactly what I had in mind.
Is Hash used in this process?
No, sort keys are compared.
Dmitry
--
For Developers, A Lot Can Happen In A Second.
Boundary is the first
21.04.2012 19:13, Dimitry Sibiryakov wrote:
Theoretically: if used, may it be more effective than quick sort for grouping
the same
key values?
If you speak *only* about grouping, then I believe you should compare
hash aggregate vs sort aggregate as different data access methods, not
hash
20.04.2012 18:02, Philippe Makowski wrote:
Dmitry, may be that's a way to improve our networking performance more
generally
There could be different ways. But I cannot think about them all at once.
Dmitry
--
For
19.04.2012 11:22, Mark Rotteveel wrote:
Thanks. I also created a ticket to see if it is easy to change Jaybird to
use the hashed authentication for Jaybird 2.2, but I don't want to do major
changes in the wire protocol for Jaybird 2.2 (I had that planned for 2.3).
It has very little to do
1001 - 1100 of 1223 matches
Mail list logo
