On 12/06/2019 10:18, Dimitry Sibiryakov wrote:
> 12.06.2019 13:43, Adriano dos Santos Fernandes wrote:
>> Then we will not have a single source of truth anymore.
>>
>> When user will create a client timestamp-tz value, he will need to fill
>> that fields too, manu
On 11/06/2019 16:52, Vlad Khorsun wrote:
> 11.06.2019 22:28, Adriano dos Santos Fernandes wrote:
>> On 11/06/2019 13:08, Vlad Khorsun wrote:
>>>> He may also do not use fbclient to format (convert from/to ts to
>>>> string)
>>>> or convert
On 11/06/2019 18:46, Vlad Khorsun wrote:
> 12.06.2019 0:23, Dimitry Sibiryakov wrote:
>> 11.06.2019 21:52, Vlad Khorsun wrote:
>>> I want to eliminate needs to translate something at client side.
>>
>> The simplest way would be to drop IDs and deliver to client only
>> bias. It is enough for
On 11/06/2019 12:20, Adriano dos Santos Fernandes wrote:
> On 11/06/2019 12:13, Karol Bieniaszewski wrote:
>>>> as the field stores the UTC time
>>
>>
>> I know naive but..
>>
>> If conversion table is not available then if it is stored as utc
On 11/06/2019 13:08, Vlad Khorsun wrote:
>> He may also do not use fbclient to format (convert from/to ts to string)
>> or convert (with/without timestamp) and uses others ways.
>
> What other ways ? Nobody understand what is our region code.
>
We can add API function to convert from/to
On 11/06/2019 13:25, Vlad Khorsun wrote:
> 11.06.2019 18:13, Karol Bieniaszewski wrote:
>
>> PS. one more dll is not the problem for me, but maybe for others..
>
> 3 dlls and 1 dat file (~30MB in common), look at regular server
> distribution.
> Probably not all 3 dll's is required for TZ
On 11/06/2019 11:51, Dimitry Sibiryakov wrote:
> 11.06.2019 16:41, Paul Reeves wrote:
>> It seems to me that the implementation of CURRENT_TIME/STAMP is the
>> wrong way round. It should support the old behaviour.
>
> It does, but you must put "execute statement 'set time zone bind
> legacy'"
On 11/06/2019 12:13, Karol Bieniaszewski wrote:
>
> >> as the field stores the UTC time
>
>
>
> I know naive but..
>
> If conversion table is not available then if it is stored as utc why
> not showing it as
>
> „15:09:49 UTC”?
>
>
>
> PS. one more dll is not the problem for me, but maybe for
On 11/06/2019 11:41, Paul Reeves wrote:
> On Tue, 11 Jun 2019 11:10:54 -0300
> Adriano dos Santos Fernandes wrote:
>
>> On 11/06/2019 11:08, Dimitry Sibiryakov wrote:
>>> 11.06.2019 15:41, liviuslivius wrote:
>>>> Can i ask what is the problem? When i re
On 11/06/2019 11:22, liviuslivius wrote:
> >>from rdb$database - BOOM!
> But why is that boom?
> Why not show e.g.
> 11.06.2019 16:08 (GMT+01:00)?
>
> This does require some conversion? This is stored during save process.
>
>
if user uses +01:00 (offset) it should work. If user uses a region, it's
On 11/06/2019 11:08, Dimitry Sibiryakov wrote:
> 11.06.2019 15:41, liviuslivius wrote:
>> Can i ask what is the problem? When i retrive data by client lib it
>> try to convert it to local timezone or what?
>
> Copy isql + fbclient.dll somewhere, connect to any database, select
>
On 11/06/2019 08:33, Alex Peshkoff via Firebird-devel wrote:
> What you mean by install?
>>
>> Copy one .dll + .msg file is not install.
>>
>> Copy more than one .dll + .msg file is install?
>
> Adriano, users prefer to copy just one .dll (in many cases .msg is not
> needed). Single file.
>
ICU
On 11/06/2019 09:32, Vlad Khorsun wrote:
>
> You trying to speculate on other issues to hide current one.
> It will not work.
> Issue will not disappear.
>
It's the same. You don't want to use icu DLL but use others DLLs that is
not always available in Windows.
> So, all you can think on is
On 11/06/2019 08:33, Alex Peshkoff via Firebird-devel wrote:
>> What you mean by install?
>>
>> Copy one .dll + .msg file is not install.
>>
>> Copy more than one .dll + .msg file is install?
>
> Adriano, users prefer to copy just one .dll (in many cases .msg is not
> needed). Single file.
>
At
On 11/06/2019 08:33, Vlad Khorsun wrote:
>>> This is pure demagogy. The problem is not what i like or not like.
>>> The problem is that your "software design" makes Firebird to be less
>>> and less attrictive for people. Small client with no need to install
>>> was a strong point of a Firebird
On 11/06/2019 07:57, Vlad Khorsun wrote:
> 11.06.2019 13:34, Adriano dos Santos Fernandes wrote:
>> On 11/06/2019 03:56, Vlad Khorsun wrote:
>>> 11.06.2019 2:15, Adriano dos Santos Fernandes wrote:
>>>> On 10/06/2019 19:41, Vlad Khorsun wrote:
>>>>
>>
On 11/06/2019 03:56, Vlad Khorsun wrote:
> 11.06.2019 2:15, Adriano dos Santos Fernandes wrote:
>> On 10/06/2019 19:41, Vlad Khorsun wrote:
>>
>> ...
>>
>> Vlad, first of all, please say me what's the difference with Linux
>> fbclient that has libtommath as
On 10/06/2019 19:41, Vlad Khorsun wrote:
...
Vlad, first of all, please say me what's the difference with Linux
fbclient that has libtommath as dependency since v3.
Also note that libtommath does not even have a stable version/name
across Ubuntu versions...
Adriano
Firebird-Devel mailing
All,
Please review.
https://github.com/FirebirdSQL/firebird/pull/205
Adriano
Firebird-Devel mailing list, web interface at
https://lists.sourceforge.net/lists/listinfo/firebird-devel
On 25/05/2019 07:24, Vlad Khorsun wrote:
>>
>> Do you see any problem to stop backtracking on these places?
>
> Usage of YYVALID seems as correct way to fix the problem, but... first
> explain
> please - why do you mark both rules as valid and why it solves the issue ?
>
> Note, in test\t2.y
Hi!
We have ugly things related to API functions and public headers:
- Different ibase.h files
- why_proto.h API duplication
- FB_COMPILING_WHY_CPP
- different include files used internally and published
- different types (ISC_USHORT vs USHORT) used in same functions
- alt.cpp also implement API
Components: API / Client Library
Reporter: Adriano dos Santos Fernandes
The subdirectory "impl", necessary for users, is not published.
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrat
On 29/04/2019 14:59, Vlad Khorsun wrote:
> 29.04.2019 20:42, Gabor Boros wrote:
>
>> Windows builds are not fresh.
>
> You may try AppVeyor builds:
>
> https://ci.appveyor.com/project/FirebirdSQL/firebird/history
>
Clicking in a build, a job name, then Artifacts...
Adriano
Firebird-Devel
On 26/04/2019 16:26, Leyne, Sean wrote:
> Adriano,
>
> Definitely an interesting article.
>
> By posting it to this list, were you thinking that the code could be of
> benefit to Firebird?
>
> If so, any specific areas you were proposing?
>
Firebird uses hash tables for joins and others
https://code.fb.com/developer-tools/f14/
Firebird-Devel mailing list, web interface at
https://lists.sourceforge.net/lists/listinfo/firebird-devel
On 24/04/2019 09:57, Jiří Činčura wrote:
>> I'm not against tools to help one fix timestamps after rule change, but
>> definitively that should be tools, not the storage of values that should
>> be changed.
> What I'm trying to say, that simply storing in UTC+TZ is not enough, because
> at the
On 24/04/2019 03:53, Jiří Činčura wrote:
>> That is not a problem. The ambiguity exists only when transforming a
>> timestamp+TZ (as one sees it) to UTC. After parse the literal, it's
>> always in UTC+TZ.
>>
>> UTC+TZ is always transformed to a valid displayable timestamp+TZ.
> That is a BIG
On 23/04/2019 14:43, Jiří Činčura wrote:
> Regarding the exception, what would happen if you store valid date at
> that time and you later, with new DST rules, try to read it?
>
>
That is not a problem. The ambiguity exists only when transforming a
timestamp+TZ (as one sees it) to UTC. After parse
Hi!
With time zones, there is some timestamps that does not exist or are
"ambiguous".
For example, timestamp '2017-10-15 00:00 America/Sao_Paulo' does not
exist as it's in the gap where DST starts and had one hour advanced.
And timestamp '2018-02-17 23:00 America/Sao_Paulo' are ambiguous as it
Affects Versions: 4.0 Beta 1
Reporter: Adriano dos Santos Fernandes
Sometimes running TCS tests some errors appears:
Invalid time zone region: America/Los_Angeles0
or
Invalid time zone region: America/Los_Angeles1
Some garbage character may be read after the string bounds
Versions: 4.0 Beta 1
Reporter: Adriano dos Santos Fernandes
ISQL has a lot of issues with increased identifier length.
Due to hard-coded buffers size many operations may fail (malfunction or crash).
--
This message is automatically generated by JIRA.
-
If you think it was sent
: Firebird Core
Issue Type: Bug
Components: Engine
Affects Versions: 4.0 Beta 1
Reporter: Adriano dos Santos Fernandes
The standard says that at routine invocation, "the value of the original time
zone displacement is set to the value of the current time
/browse/CORE-6026
Project: Firebird Core
Issue Type: Bug
Components: API / Client Library, UDF
Affects Versions: 4.0 Beta 1, 3.0.4
Reporter: Adriano dos Santos Fernandes
In Linux 32-bits alignment of BIGINT, SCALED_BIGINT, DECFLOAT16 and DECFLOAT34
On 13/03/2019 17:04, Vlad Khorsun wrote:
>
> Sorry, it is still not clear - how one could know if node requires
> "specialization" ?
> Imagine a new developer who want to create new kind of Nodes - what is
> formal
> criteria of "specialized" node ?
>
> Currently it could be detected by
On 12/03/2019 17:22, Vlad Khorsun wrote:
>>
>> Let me demonstrate it. With this (wrong) patch now the code compiles:
>>
>> --
>> diff --git a/src/dsql/ExprNodes.cpp b/src/dsql/ExprNodes.cpp
>> index 4ff5253a2b..26f826ae09 100644
>> --- a/src/dsql/ExprNodes.cpp
>> +++
On 11/03/2019 09:35, Vlad Khorsun wrote:
>
> I just committed few patches and have few more things to ask here:
>
Vlad, the change just broke reason for NodeRef/NodeRefImpl existence
(which is still commented but not working):
// This class and NodeRefImpl exists for nodes to replace
On 11/03/2019 06:37, Alex Peshkoff via Firebird-devel wrote:
> On 3/10/19 1:56 AM, Adriano dos Santos Fernandes wrote:
>> Here is a patch that changes FB_MESSAGE alignment to match Firebird
>> definitions.
>>
>> I have purposely didn't tested for C++11 to use alig
/non-Linux.
That code assumes only Linux is problematic now, but maybe all
non-Windows are?
Adriano
On 08/03/2019 14:48, Adriano dos Santos Fernandes wrote:
> On 07/03/2019 13:19, Adriano dos Santos Fernandes wrote:
>> Decimal64 seems to be some 64-bit integers in sequence,
On 07/03/2019 13:07, Dimitry Sibiryakov wrote:
>
> Just imagine fbclient loaded into a process compiled with compiler
> where ISC_TIMESTAMP_TZ is 10 bytes long (for example Delphi with
> forced packed records).
>
>
If you change Win32 API structs to packed it will crash as well, so
don't change
On 07/03/2019 12:47, Dmitry Yemanov wrote:
> 07.03.2019 18:25, Adriano dos Santos Fernandes wrote:
>>
>> But it how IB/FB always worked. Types are defined in platform specific
>> way to have correctly sizes. As sizes are fixed they align correctly
>> with existing platf
On 07/03/2019 12:51, Dimitry Sibiryakov wrote:
> 07.03.2019 16:47, Dmitry Yemanov wrote:
>> For *_TZ types, alignment is not a problem, the size is. Or at least
>> it may look weird - UTC+TZ together occupy 10 bytes but sqllen
>> returns 12 bytes.
>
> And code will get crashed on
On 07/03/2019 06:53, Dmitry Yemanov wrote:
> 04.03.2019 23:01, Mark Rotteveel wrote:
>>
>> My question is about the **encoding** in the data buffer obtained
>> from the native client. I want to avoid incorrectly implementing the
>> support in Jaybird. And FYI, In the wire protocol 16 bit integers
On 07/03/2019 06:52, Vlad Khorsun wrote:
>
> Database creation time mostly contains from compiling and parsing
> requests.
> Unfortunately, it is slower in fb4 than fb3 and fb3 is much slower
> than fb25.
> IIRC, it was said here sometime ago and some improvement was made, but
> it is
> still
On 04/03/2019 11:08, Adriano dos Santos Fernandes wrote:
> On 04/03/2019 10:57, Alex Peshkoff via Firebird-devel wrote:
>> On 3/4/19 3:15 PM, Vlad Khorsun wrote:
>>> 04.03.2019 14:01, Alex Peshkoff via Firebird-devel wrote:
>>>> On 3/4/19 2:57 PM, Vlad Khorsun wr
On 04/03/2019 11:08, Adriano dos Santos Fernandes wrote:
> On 04/03/2019 10:57, Alex Peshkoff via Firebird-devel wrote:
>> On 3/4/19 3:15 PM, Vlad Khorsun wrote:
>>> 04.03.2019 14:01, Alex Peshkoff via Firebird-devel wrote:
>>>> On 3/4/19 2:57 PM, Vlad Khorsun wr
On 04/03/2019 10:57, Alex Peshkoff via Firebird-devel wrote:
> On 3/4/19 3:15 PM, Vlad Khorsun wrote:
>> 04.03.2019 14:01, Alex Peshkoff via Firebird-devel wrote:
>>> On 3/4/19 2:57 PM, Vlad Khorsun wrote:
>>
I have additional question: is it true that fbclient now depends
on ICU ?
>>>
URL: http://tracker.firebirdsql.org/browse/CORE-6018
Project: Firebird Core
Issue Type: New Feature
Components: Engine
Reporter: Adriano dos Santos Fernandes
With this feature it's possible to create parallel (via different attachments
Project: Firebird Core
Issue Type: Task
Affects Versions: 4.0 Beta 1
Reporter: Adriano dos Santos Fernandes
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
http
: Engine
Reporter: Adriano dos Santos Fernandes
This info code returns the same as RDB$GET_CONTEXT('SYSTEM', 'SNAPSHOT_NUMBER')
running in snapshot transaction.
In READ COMMITTED READ CONSISTENCY transaction, different than
RDB$GET_CONTEXT('SYSTEM', 'SNAPSHOT_NUMBER
On 01/03/2019 10:28, Vlad Khorsun wrote:
> 01.03.2019 13:16, Adriano dos Santos Fernandes wrote:
>
>> I am assuming nobody objects and will implement the changes in the
>> branch.
>
> No objection, just not forget to change syntax\constant names as was
> agreed recen
On 25/02/2019 13:21, Adriano dos Santos Fernandes wrote:
> Vlad is proposing the new info code to be named
> fb_info_tra_snapshot_number. I have no problem with it, provided that
> SNAPSHOT_CN is also renamed (with he seems to be open), but for what?
> SNAPSHOT_NUMBER too? (I hav
On 01/03/2019 07:43, Dimitry Sibiryakov wrote:
> 01.03.2019 11:32, Alex Peshkoff via Firebird-devel wrote:
>> But if one writes some funny plugin which generates random names in
>> authentication block - definitely yes :)
>
> They don't need to be random. I can imagine cases when they are a)
>
On 28/02/2019 17:09, Dimitry Sibiryakov wrote:
> 28.02.2019 20:42, Adriano dos Santos Fernandes wrote:
>> Then the question: for what the client would need to known the mapped
>> user name?
>
> The simplest example: connection pool must grouped by user name
> because c
On 28/02/2019 16:54, Mark Rotteveel wrote:
>
> The same can be asked for a lot of other information items that can be
> obtained from isc_database_info. And the answer is invariably: because
> it can be useful for an application or a driver itself to obtain that
> information.
>
Why it could be
On 28/02/2019 16:20, Mark Rotteveel wrote:
>
> As far as I understand it, if you use the Firebird 3 mapping feature,
> than you can remap the login and role of any user to an entirely
> different user.
>
> So, as far as I know, a client no longer knows what the actual user
> is, even if it used
Hi!
As part of READ COMMITTED READ CONSISTENCY, it was added context
variables (under RDB$GET_CONTEXT's SYSTEM namespace) GLOBAL_CN and
SNAPSHOT_CN.
GLOBAL_CN: Most current value of global Commit Number counter
SNAPSHOT_CN: Value of Commit Number of currently database snapshot:
either
On 25/02/2019 08:00, Lester Caine wrote:
>
>
> Keeping PHP working with Firebird is a major headache anyway and the
> interface does need some attention from someone more capable on the C
> side than me but simply working through the Firebird side what is the
> SAFE way to update the installation
On 24/02/2019 08:23, Vlad Khorsun wrote:
> TPB: isc_tpb_snapshot_commit_number,
isc_tpb_snapshot_number
Regards,
Vlad
PS we also must add isc_info_tra_snapshot_number and, probably,
context variable.
Don't we already have context SNAPSHOT_CN? It
On Sat, Feb 23, 2019, 21:30 Vlad Khorsun wrote:
> 23.02.2019 21:14, Adriano dos Santos Fernandes wrote:
> > Hi!
> >
> > After changes to use commit number instead of base transaction number, I
> > offer to make that interfaces for the feature:
>
>I offer to n
Hi!
After changes to use commit number instead of base transaction number, I
offer to make that interfaces for the feature:
SQL command: SET TRANSACTION SNAPSHOT COMMIT NUMBER
(some variant as SNAPSHOT FROM COMMIT NUMBER or SNAPSHOT BASE COMMIT
NUMBER may be acceptable)
TPB:
On 19/02/2019 13:56, Vlad Khorsun wrote:
>
> As i understand you - it doen't break anything. For me, it is safe to
> assign
> to the new snapshot (CONCURRENCY) transaction number of already existing
> and
> still alive snapshot. It is very important to ensure existence of that
> snapshot
>
Hi Vlad,
I restarted work on this feature now using commit numbers.
Initial prototype seems to work easily.
So now with current master code, is it ok to have transaction numbers
TN1 < TN2 < TN3 with their correspondents tra_snapshot_number not being
TSN1 <= TSN2 <= TSN3 ?
That is, when TN3
Components: Engine
Affects Versions: 4.0 Beta 1
Reporter: Adriano dos Santos Fernandes
Open two connections C1 and C2.
C2: select current_transaction from rdb$database; -- let's call the
result T2
C2: commit;
C1: select rdb$get_transaction_cn(T2) from rdb$database;
In Super
On 18/02/2019 08:47, Adriano dos Santos Fernandes wrote:
> On 18/02/2019 08:37, Vlad Khorsun wrote:
>>
>> Seriously, if you (and others) consider it is important enough to
>> try to refresh
>> TIP cache in such cases - fill the ticket in tracker and i'll fix it.
On 18/02/2019 08:37, Vlad Khorsun wrote:
>
>
> Seriously, if you (and others) consider it is important enough to
> try to refresh
> TIP cache in such cases - fill the ticket in tracker and i'll fix it.
>
If the change is going to appear only in Beta 2, then ok and I file a
ticket. Otherwise a
On 16/02/2019 12:57, Mark Rotteveel wrote:
>
> BTW: similar arguments could be made for the SET DECFLOAT options, but
> I don't have a need there.
>
The similar SET DECFLOAT wasn't it, so TIME ZONE didn't had too.
Adriano
Firebird-Devel mailing list, web interface at
On 18/02/2019 05:50, Vlad Khorsun wrote:
> 18.02.2019 1:49, Adriano dos Santos Fernandes wrote:
>> Open two connections C1 and C2.
>>
>> C2: select current_transaction from rdb$database; -- let's call the
>> result T2
>> C2: commit;
>>
>> C1: select
On 17/02/2019 08:33, Mark Rotteveel wrote:
> It would be helpful if Firebird already had an explicit default value
> (as then I can just document that, and I don't need to have logic to
> treat a Jaybird specific value as 'don't set').
I don't think it should. Just don't add it to DPB.
Adriano
On 17/02/2019 08:08, Mark Rotteveel wrote:
> Does isc_dpb_session_time_zone have an explicit default value? What I
> mean is, can you set a value (maybe local?) that behaves as if the value
> is not set (and thus uses the DefaultTimeZone config or system time zone)?
>
No.
> In addition, is
Open two connections C1 and C2.
C2: select current_transaction from rdb$database; -- let's call the
result T2
C2: commit;
C1: select rdb$get_transaction_cn(T2) from rdb$database;
In Super C1 returns the commit number. In Classic it returns NULL.
Adriano
Firebird-Devel mailing list, web
On 15/02/2019 09:29, Paul Reeves wrote:
> On Fri, 15 Feb 2019 11:50:11 +0100
> Dimitry Sibiryakov wrote:
>
>> 15.02.2019 9:17, Paul Reeves wrote:
>>> First you need to click on the 'Desktop Development with C++'
>>You are talking about installing of Visual Studio. My question was
>>
On 02/02/2019 12:09, Mark Rotteveel wrote:
> In the Firebird sources, TimeZoneUtil::MAX_LEN is defined as 32, however
> the column RDB$TIME_ZONES.RDB$TIME_ZONE_NAME is defined as CHAR(63).
>
> There currently is one time zone name with length 32 (the rest is
> shorter), so right now there is no
On 08/02/2019 16:54, Karol Bieniaszewski wrote:
>
> Or better sample
>
>
>
> VAR_S[5] = VAR_A[3];
>
> VAR_S[3] = VAR_A[5];
>
>
>
> Vs
>
>
>
> VAR_S = SUBSTRING(VAR_S FROM 1 FOR 2) || SUBSTRING(VAR_A FROM 5 FOR 1)
> || SUBSTRING(VAR_S FROM 4 FOR 1) || SUBSTRING(VAR_A FROM 3 FOR 1) ||
On 08/02/2019 16:10, Karol Bieniaszewski wrote:
>
>
> I understand that this require implementation time and team resources.
>
> And as any feature it require future maitenance.
>
> But without this, speed of string manipulations is not efficient and
> database require to have optimized speed in
On 31/01/2019 09:41, Gabor Boros wrote:
> Hi All,
>
> I don't know who fixed/resurrected it but... Thank you very much! Much
> more easier to follow the development with it.
>
The checkins list were running in firebird-check...@googlegroups.com for
some time, and now probably in both addresses
On 24/01/2019 12:20, Jiří Činčura wrote:
>> But if we have some libraries in the application loading Firebird, and
>> the application writer does not have total control of that, two
>> libraries may load Firebird and when one of them calls the shutdown
>> function, the other will not work anymore.
On 24/01/2019 12:00, Vlad Khorsun wrote:
> 24.01.2019 15:13, Jiří Činčura wrote:
>> Vlad, is it OK to call this method multiple times (nothing else is
>> called in between)?
>
> Yes. All calls after first one is (almost) no-op
>
>> I'm asking because some application might load same library
On 20/01/2019 20:42, Jorge Gonçalves wrote:
> I'm using Firebird-4.0.0.1378-0_x64 and it seems that the timezone
> database is missing
>
> for example the statement
> "select rdb$time_zone_util.database_version() from rdb$database;"
>
> returns
> DATABASE_VERSION
>
>
Components: Engine
Affects Versions: 3.0.4, 4.0 Alpha 1
Reporter: Adriano dos Santos Fernandes
Currently optimizer do not use index for IS DISTINCT FROM {TRUE
| FALSE | NULL}
While it seems ok that IS DISTINCT FROM does not use index for others field
types, it could be more
: Adriano dos Santos Fernandes
- NULL IS {FALSE | TRUE} should be FALSE, but Firebird gives NULL
- NULL IS NOT {FALSE | TRUE} should be TRUE, but Firebird gives NULL
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
http
On 11/01/2019 15:25, Alex Peshkoff via Firebird-devel wrote:
>
> PS. Personally I would prefer not to build any public binaries (except
> may be docker) at all. Most of open source projects go that way.
My experience is that many projects delivers .deb packages for Ubuntu.
Adriano
On 30/12/2018 07:22, Mark Rotteveel wrote:
>
> The error is now:
>
> """
> RAMONA Sun Dec 30 09:59:28 2018
> ICU error (0) retrieving the system time zone (W. Europe Standard
> Time). Falling back to displacement.
> """
>
That's because Windows build is still with old ICU without time zone
On Sat, Dec 29, 2018, 07:17 Mark Rotteveel I was doing an artificial performance test on Firebird by inserting into
> a table that had a column
>
> updatedts timestamp default localtimestamp
>
> The insert did not touch this column (so the default is applied). To my
> surprise, that was about 7 -
On 09/12/2018 11:55, Mark Rotteveel wrote:
> Back in 2012 I created CORE-3808 to request support for RETURNING *,
> which should - equivalent to SELECT * - return all columns instead of
> having to manually include all columns in the returning clause.
>
> The primary use case for me would be to
On 26/11/2018 09:24, Dimitry Sibiryakov wrote:
> 26.11.2018 11:54, Dimitry Sibiryakov wrote:
>> no functionality is depended on it with such precision that would
>> require taking time zone into account.
>
> Besides, storage change is not enough, INF items must be changed
> accordingly and it
On 23/11/2018 14:31, Dimitry Sibiryakov wrote:
>
>>> Do we need timezone there at all?
>>
>> Yes. I we do not want to have half-done TZ support.
>
> Isn't UTC better there?
>
It's an option. But we lose TZ from who created it.
It would be ok for me if others agree.
Adriano
Hi!
Isn't this utility obsolete? Could it be removed in master?
Adriano
Firebird-Devel mailing list, web interface at
https://lists.sourceforge.net/lists/listinfo/firebird-devel
Hi!
Does anyone see any problem in extending (in time zones branch)
hdr_creation_date to include the time zone?
Adriano
Firebird-Devel mailing list, web interface at
https://lists.sourceforge.net/lists/listinfo/firebird-devel
On 06/11/2018 09:57, Dimitry Sibiryakov wrote:
> 06.11.2018 7:34, Alex Peshkoff via Firebird-devel wrote:
>> An idea was to have same behavior for remote and embedded
>> connections, please read doc/README.fb_shutdown, pay attention at
>> fb_shut_confirmation and a sample in the end.
>
> All
On 03/11/2018 12:55, Mark Rotteveel wrote:
> The Windows snapshots of Firebird 4 haven't been updated since the
> 31st of October, while the Linux snapshot was last updated today (the
> 3rd of November).
>
Because there were no commits since then?
Adriano
Firebird-Devel mailing list, web
On 26/10/2018 12:01, Lester Caine wrote:
> On 26/10/2018 14:53, Dmitry Yemanov wrote:
>> Yes, it gonna be merged from PR soon.
>>
>> What is the status for time zone support? Is it going to be
>> included in
>> Firebird 4 or not?
>
> But the very limited mechanism being included does not
On 25/10/2018 00:01, nonomura wrote:
>
> (2018/10/24 17:51), Adriano dos Santos Fernandes wrote:
>> As I said for you *many* times: if UNICODE (sensitive) has problems, as
>> it has,
> Nobody seems supporting your assumption.
>
Ok then.
>> how can you changing co
As I said for you *many* times: if UNICODE (sensitive) has problems, as
it has, how can you changing code under the insensitive flags condition
will fix the problem?
Adriano
On 24/10/2018 03:20, nonomura wrote:
> The source code cited below clearly tells the root of the problem that
> I
On 23/10/2018 11:36, Mark Rotteveel wrote:
> On 23-10-2018 16:20, liviuslivius wrote:
>> Really strange "standard" here...
>
> Standards are nothing but inconsistent, especially as they evolve over
> time. However, CURRENT_TIME dates back to at least the SQL:92 standard
> (and probably existed
On 19/10/2018 09:42, nonomura wrote:
> (2018/10/19 19:03), Adriano dos Santos Fernandes wrote:
>> ICU generates sort key for a single string. For multi segment
>> (columns) index/sort, Firebird call ICU (or any collation) for each
>> column and join the generated fully (with
On 19/10/2018 06:24, nonomura wrote:
> Adriano,
>
> I've read your comment again, carefully, and understood what you were
> thinking as
> "the root of the problem".
>
> But I could not understand how it is relating to the case that I
> reported.
>
> ICU library generates sort keys for those three
I'm really trying to communicate with you here and in the tracker but
you seem to answer every point of mine as rewriting what I wrote giving
another meaning.
Or it seems you're so expert on the subject, so please send pull
request. It's very easy.
Adriano
On 18/10/2018 17:06, nonomura wrote:
I really don't understand why you emphasize so much on
case-/accent-insensitivity, and say UNICODE is ok, as we can easily
demonstrate the root of the problem of multi-level and multi-segment
with it.
Yes, there is inconsistencies with insensitive with/without unique, but
root of the problem
Please check this recent discussion, that internally is about the same
thing:
http://tracker.firebirdsql.org/browse/CORE-5940
Also, please change UNICODE_CI_AI to WIN_PTBR (with WIN1252 charset) in
your test. I believe the problem will not show on this condition, as
it's a MULTI-LEVEL=0
On 30/09/2018 06:25, Dimitry Sibiryakov wrote:
> 30.09.2018 4:52, Adriano dos Santos Fernandes wrote:
>> - Instead of agg_finished, adjust SUSPEND (probably with another
>> keyword) to somehing like: SUSPEND WHEN FETCHED DO WHEN
>> FINISHED DO
>
> Isn't it h
501 - 600 of 1691 matches
Mail list logo
