On 2020-05-27 14:34, Dimitry Sibiryakov wrote:
27.05.2020 13:31, Alex Peshkoff via Firebird-devel wrote:
It does not know what sysdba password to use.
That's fine, let it just create the security database and data
structures but not the user.
But that will do things even more obscure
On 2020-05-27 14:26, Vlad Khorsun wrote:
27.05.2020 10:58, Alex Peshkoff via Firebird-devel wrote:
On 2020-05-26 19:16, Ivan Přenosil wrote:
Not sure where to report this one ...
When trying to work with uninitialized security database in FB4 the
server will raise error, e.g.
SQL> conn
On 2020-05-27 14:29, Dimitry Sibiryakov wrote:
27.05.2020 13:26, Vlad Khorsun wrote:
In my opinion, the message should be more informative for end user,
show waht to do to fix error and refers to the documentation only in
order to get a full explanation.
May be it would be better if the
On 2020-05-26 19:16, Ivan Přenosil wrote:
Not sure where to report this one ...
When trying to work with uninitialized security database in FB4 the
server will raise error, e.g.
SQL> connect 'localhost/:Z:\x.fdb' USER SYSDBA PASSWORD 'masterkey';
Statement failed, SQLSTATE = 28000
On 2020-05-26 18:11, Ivan Přenosil wrote:
When I give wrong backup file to NBACKUP.exe -INPLACE, error is
reported as expected:
NBACKUP -inplace -restore localhost/:Z:\export\TESTF2.FDB
Z:\export\x05G.nbk
Invalid incremental backup file: Z:\export\x05G.nbk
NBACKUP -inplace -restore
On 2020-05-26 11:31, Paul Reeves wrote:
On Tue, 26 May 2020 11:18:14 +0300
Alex Peshkoff via Firebird-devel wrote:
On 2020-05-26 11:11, Mark Rotteveel wrote:
This looks like a bug in the statement parser. It seems to use signed >
16 bit int for this value, instead of an unsigned 16 bit
On 2020-05-26 11:11, Mark Rotteveel wrote:
This looks like a bug in the statement parser. It seems to use signed
16 bit int for this value, instead of an unsigned 16 bit int (or a
signed 32 bit int). This does make me wonder about the test coverage
for this feature.
Could you create a bug in
On 2020-05-21 19:08, Emil Totev wrote:
I am happily using Firebird 4 Beta2 to serve transparently both ODS12
and ODS13 databases, by adding Engine12 to the providers list.
However, when creating a new database either by ISQL's CREATE DATABASE
or gbak -c, the server always uses the first,
On 2020-05-20 22:04, Adriano dos Santos Fernandes wrote:
https://devblogs.microsoft.com/commandline/windows-package-manager-preview/
At the first glance appears very promising
Firebird-Devel mailing list, web interface at
https://lists.sourceforge.net/lists/listinfo/firebird-devel
On 2020-05-18 13:31, Adriano dos Santos Fernandes wrote:
Do you have an alternative (that do not broke things), better than use
fixed date (as Oracle does with 0001-01-01 and it even more broke
behavior) or a recent date?
Telling true I have bug desire to answer that error 'Invalid
operation'
On 2020-05-16 05:22, Adriano dos Santos Fernandes wrote:
On 15/05/2020 12:46, Mark Rotteveel wrote:
The decision to use 2020-01-01 as date for some of the time with time
zone conversion leads to, in my opinion, confusing behaviour:
select
time'13:25:32.1235 Europe/Amsterdam' at time zone
On 2020-05-15 21:40, Jorge Gonçalves wrote:
I already have to fb3 running alongside fb4
but with some strange problems ..
some examples :
I've tried to reproduce on linux but used fresh fb3 snapshot. (3.0.4 is
bad choice for given attempt - see
On 2020-05-08 15:43, Tony Whyman wrote:
Finally got round to working out why there was a problem.
If I change the Wirecrypt setting in firebird.conf to
#WireCryptPlugin = ChaCha, Arc4
WireCryptPlugin = Arc4
then everything works fine.
I have downloaded today's snapshot and the same problem
On 2020-04-30 12:12, Tony Whyman wrote:
In the README.time_zone, the SET BIND OF TIME ZONE TO EXTENDED is
described as being intended to "solve a problem of representing
correct time on clients missing ICU library".
All the text I can find, discusses how this is used when reading a
TIMESTAMP
On 2020-04-30 12:10, Tony Whyman wrote:
All I get when trying to use the current snapshot and opening a
database is the error message "Invalid Clumplet buffer structure: path
length doesn't match with clumplet".
I am using a test program that works with all previous versions of
Firebird.
On 2020-04-28 16:55, Tony Whyman wrote:
2. There is a risk of a stealth (ICU) upgrade under Linux if the
upgrade affects indexes that depend upon character set collation
sequences.
FYI - gfix is ready to help with this, it's enough to use switch:
-icu fix database to be
On 2020-04-29 20:11, Alex Peshkoff via Firebird-devel wrote:
On 2020-04-29 18:09, Dmitry Sibiryakov wrote:
Hello, All.
What should be the behavior of getSegment() reading the last
segment of the BLOB?
a) Return some data of non-zero length and return RESULT_OK, next
call shall return
On 2020-04-29 18:09, Dmitry Sibiryakov wrote:
Hello, All.
What should be the behavior of getSegment() reading the last segment
of the BLOB?
a) Return some data of non-zero length and return RESULT_OK, next call
shall return zero length data and RESULT_NO_DATA;
b) Return some data of
On 2020-04-29 19:34, Dmitry Yemanov wrote:
29.04.2020 18:50, Dmitry Yemanov wrote:
Client side cursor appears not too complex at the first glance, but
not sure do we want to have client or server side cursor.
Scrollable cursor is already materialized at the server side, so I
see no point
On 2020-04-29 18:50, Dmitry Yemanov wrote:
29.04.2020 17:50, Alex Peshkoff wrote:
Client side cursor appears not too complex at the first glance, but
not sure do we want to have client or server side cursor.
Scrollable cursor is already materialized at the server side, so I see
no point
On 2020-04-29 08:19, Dmitry Yemanov wrote:
29.04.2020 00:36, Karol Bieniaszewski пишет:
May i ask if this is big developmenet cost to support it on the
client side api?
It's supported in the API, but not supported in the remote protocol.
IIRC, it can be easily implemented if a scrollable
On 2020-04-22 16:25, Tony Whyman wrote:
While on the subject of incompleteness in the Firebird 3 API, I never
found any alternative to the following utility functions from the
legacy API.
isc_sqlcode
isc_sql_interprete
isc_interprete
isc_event_counts
isc_event_block
isc_free
This is not a
On 2020-04-14 16:45, Willian do Amor wrote:
I have the dedicated database server running inside Hyper-V. This VM
is running Ubuntu 18.04, with 32 GB of RAM, 8 virtual processor cores
and 1 TB HD.
The Firebird that runs on that server is Classic Server 2.1. I have
only 4 databases on that
On 06.04.2020 20:01, Leyne, Sean wrote:
Alex,
If we keep it, let's decide what new tables can be ignored when
restoring backwards and what ones are mandatory and thus should raise
an error. We may also consider going half-way and limiting the
backward restore to the one prior ODS version --
On 06.04.2020 18:28, Leyne, Sean wrote:
If we keep it, let's decide what new tables can be ignored when restoring
backwards and what ones are mandatory and thus should raise an error. We
may also consider going half-way and limiting the backward restore to the
one prior ODS version -- this
On 06.04.2020 12:10, Mark Rotteveel wrote:
On 2020-04-05 21:49, Adriano dos Santos Fernandes wrote:
On 05/04/2020 12:40, Mark Rotteveel wrote:
If we do decide to follow the standard in this regard, then I would
recommend that we make an exception for the conversion applied by the
bind of TIME
On 2020-04-03 13:57, Dimitry Sibiryakov wrote:
Regardless of subj: does call getOutputMetadata() cause network
round trip?
Sometimes but typically not. If appropriate metadata was not pefetched
by prepare() call (see last parameter flags, family of
PREPARE_PREFETCH_* constants) - yes,
On 2020-04-03 13:19, Dimitry Sibiryakov wrote:
03.04.2020 12:07, Alex Peshkoff via Firebird-devel wrote:
unknown format of output message - use format automatically generated
based on properties of fields in a query
not known yet format of output message - format will be passed after
On 2020-04-03 12:55, Dimitry Sibiryakov wrote:
03.04.2020 11:44, Alex Peshkoff via Firebird-devel wrote:
In doc I see "unknown format of output message", that's not same case
as "not known yet". Pay attention - "firebird is using in this case
default message format&quo
On 2020-04-03 12:20, Dimitry Sibiryakov wrote:
03.04.2020 10:33, Alex Peshkoff via Firebird-devel wrote:
Delayed metadata arrives only with first fetch call.
It is fine, but documentation says that in such cases (when output
metadata is not known yet) openCursor() is called with NULL
On 2020-04-02 18:55, Dimitry Sibiryakov wrote:
02.04.2020 17:33, Dimitry Sibiryakov wrote:
Can someone explain how DELAYED_OUT_FORMAT works and its purpose
in general?
To be precise, here is a piece of call log from my provider:
0037ce20 ODBCAttachment::prepare("select Point_ID,
On 2020-03-25 17:19, Jiří Činčura wrote:
Hi,
the length for null flag (IMessageMetadata::getNullOffset) is 1 byte or 2 bytes?
2 bytes (i.e. sizeof short, 16 bits)
Firebird-Devel mailing list, web interface at
https://lists.sourceforge.net/lists/listinfo/firebird-devel
On 2020-03-24 19:50, Vlad Khorsun wrote:
Added first in Provider::generateDPB(), next in
(any-)Connection::attach().
Vlad, I'm unsure - what place is correct one?
Second was added with connections pool implementation in master.
This part requires
some completion. isc_dpb_ext_call_depth
On 2020-03-24 16:41, Gregor Kobler via Firebird-devel wrote:
Hello
How can i use the clause
SET TIME ZONE BIND { NATIVE | LEGACY }
I ise Delphi Rio 10.3.3 with FireDAC. Should i made it as a parameter
somewhere at the connection component? Or should i run it as a
SQL-Statement? How can i
On 2020-03-24 12:53, Vlad Khorsun wrote:
24.03.2020 9:54, Alex Peshkoff via Firebird-devel wrote:
On 2020-03-23 22:18, Dimitry Sibiryakov wrote:
Hello, All.
Is it bug or intended?
Bug.
Not really. I see no checks in engine against duplication of any DPB
tag, it is not
described
On 2020-03-23 22:18, Dimitry Sibiryakov wrote:
Hello, All.
Is it bug or intended?
Bug. Added first in Provider::generateDPB(), next in
(any-)Connection::attach().
Vlad, I'm unsure - what place is correct one?
Firebird-Devel mailing list, web interface at
On 2020-03-23 20:18, Dimitry Sibiryakov wrote:
23.03.2020 18:13, Alex Peshkoff via Firebird-devel wrote:
Please provide wider example.
Using XpbBuilder I never needed it at client side at all.
On client side - may be. But I have to parse DPB, TPB and info
buffers in a provider
On 2020-03-23 19:42, Dimitry Sibiryakov wrote:
Hello, All.
What should be used in OO API instead of isc_portable_integer()?
Please provide wider example.
Using XpbBuilder I never needed it at client side at all.
Firebird-Devel mailing list, web interface at
On 2020-03-23 14:36, Jiří Činčura wrote:
But telling true I do not see big use in it - I'm sure that 1.5Mb make
absolutely no difference. Only as a form of following mainline :-)
It's about 19-20% difference. ;)
But strictly speaking I would be more happy with Firebird ZIP downloads to be
7z
On 2020-03-23 13:49, Dimitry Sibiryakov wrote:
04.02.2016 11:00, Alex Peshkoff wrote:
On 02/04/2016 12:38 PM, Alex Peshkoff wrote:
On 02/04/2016 12:35 PM, Dimitry Sibiryakov wrote:
When an user plugin set an error to IStatus, which character
set must be string data in?
utf8
sorry,
On 2020-03-23 10:30, Mark Rotteveel wrote:
On 22-03-2020 20:13, Jiří Činčura wrote:
Hi,
is there a reason to keep providing sources in bz2 compression? I did
a quick comparison with 7z compression:
Firebird-3.0.5.33220-0.7z: 8 230 662
Firebird-3.0.5.33220-0.tar.bz2: 9 789 316
Sure, it's not
On 2020-03-17 19:21, Dimitry Sibiryakov wrote:
Hello all.
Documentation for IStatement say this:
void free(StatusType* status) – free statement, releases interface on
success.
But what will happen on failure?
IStatement remains accessible, it's state depends upon an error.
What can
Tony (& others),
On 2020-03-09 19:48, Tony Whyman wrote:
The question then arises as to why this is not the normal way of
working? Using the client's local ICU introduces a maintenance headache.
This argument I personally hardly accept. May be for old windows
versions - yes, some
On 2020-03-06 12:43, Mark Rotteveel wrote:
I'll grudgingly implement support in Jaybird by handling it identical
to a normal TIMESTAMP WITH TIME ZONE, just in case someone configures
a bind to EXTENDED TIME(STAMP) WITH TIME ZONE.
Absolutely right solution.
Firebird-Devel mailing list,
On 2020-03-05 17:49, Mark Rotteveel wrote:
I see general benefits of communicating the actual offset always, see
also below. And I don't think it is a good idea to add a new datatype
which can have meaningful uses, only to remove it again at a later
time. That will surely break applications
On 2020-03-04 20:35, Mark Rotteveel wrote:
On 04-03-2020 18:16, Alex Peshkoff via Firebird-devel wrote:
On 2020-03-04 20:01, Mark Rotteveel wrote:
What is the purpose of introducing yet another datatype called
EXTENDED TIME/TIMESTAMP WITH TIME ZONE?
Help users missing ICU on the client
On 2020-03-04 20:01, Mark Rotteveel wrote:
What is the purpose of introducing yet another datatype called
EXTENDED TIME/TIMESTAMP WITH TIME ZONE?
Help users missing ICU on the client work with time zones.
I think this is extremely confusing, making both SQL
No. Use of them is very
On 2020-03-01 21:03, Mark Rotteveel wrote:
On 01-03-2020 18:53, Adriano dos Santos Fernandes wrote:
On 01/03/2020 09:25, Mark Rotteveel wrote:
Looking at src/common/keywords.cpp, int128 is considered a non-reserved
token (it's defined as `{TOK_INT128, "INT128", true}`), and it is
listed
in
On 2020-02-28 18:38, Dimitry Sibiryakov wrote:
Hello, All.
There is no way to get precision for numeric/decimal types from
IMessageMetadata, right?
No direct way. Only get underlying type and use a fact that actual
precision is defined in firebird by it. What about one requested in
27, 2020 at 4:01 PM Alex Peshkoff via Firebird-devel
<mailto:firebird-devel@lists.sourceforge.net>> wrote:
On 2020-02-27 17:12, Massimo Fazzolari wrote:
>
> What version of firebird do you use your UDF with?
>
>
> Classic 2.5.9.27139-0
On 2020-02-27 17:12, Massimo Fazzolari wrote:
What version of firebird do you use your UDF with?
Classic 2.5.9.27139-0
I've expected CS but 2.1 or less.
2.5 is already MT product and it always appeared that IsMultiThread in
pascal should match that fact i.e. shold be True. But all
On 2020-02-27 16:54, Massimo Fazzolari wrote:
Thank you all guys, I finally managed to fix the issue:
* There was an initialization section in one unit imported that
set IsMultiThread = True
* I removed the cthreads unit in the uses clause.
Does anybody have any clue what are the
On 2020-02-26 15:46, Paul Reeves wrote:
AFAICT most of the content of that document is rubbish. They have certainly
skewed our support costs heavily, using the most extreme examples.
It's also unclear what point version of FB3 was used - 3.0.0 or
something newer like 3.0.4. I'm sure they give
On 2020-02-24 13:25, Dimitry Sibiryakov wrote:
24.02.2020 08:52, Alex Peshkoff via Firebird-devel wrote:
That makes it possible to register builtin (or virtual like you
called them) plugins with special "builtin" module which is never
unloaded.
Yes, but only until any real plugin
On 2020-02-22 18:34, Dimitry Sibiryakov wrote:
22.02.2020 15:28, Alex Peshkoff via Firebird-devel wrote:
At least I see no reasons for it not to work.
These lines of code make me unsure:
if (!current)
{
// not good time to call this function - ignore request
On 2020-02-22 01:19, Dimitry Sibiryakov wrote:
Hello, All.
Is it possible that an application load fbclient, get PluginManager
interface and register some plugins?
Will the application then be able to use these "virtual" plugins for
encryption, tracing, etc?
AFAIU it is exactly the way
On 2020-02-17 19:40, Dimitry Sibiryakov wrote:
Hello, All.
I contrast to documentation where it is written "void
detach(StatusType* status) – replaces isc_detach_database(). On
success releases interface." provider implementation must not call
release() in detach() because YValve will do
On 2020-02-11 21:16, Dimitry Sibiryakov wrote:
11.02.2020 18:18, Alex Peshkoff via Firebird-devel wrote:
Return isc_info_error.
One funny thing there is with this item: in IB API it is always
named to be a single-byte tag the same as isc_info_end and
isc_info_truncated while everywhere
On 2020-02-11 19:22, Dimitry Sibiryakov wrote:
Hello, All.
In my own provider is it ok to silently ignore info items that are
not applicable to the provider or isc_info_error must be returned?
Return isc_info_error. Looks like client's code should be able to at
least it. Something like
On 2020-02-03 20:44, Adriano dos Santos Fernandes wrote:
On 03/02/2020 12:45, liviuslivius wrote:
Hi
It really should be rewritten/updated.
1. First select should use new type join kind not comma join kind.
2. Field po_number should be prefixed with alias of the table.
3. Order of exception
On 2020-01-31 11:05, Mark Rotteveel wrote:
I'd really appreciate a reply to this.
Sorry Mark, a bit busy with another issue (decfloat - related). Will
answer soon.
Mark
On 26-01-2020 14:01, Mark Rotteveel wrote:
The RFC-8439 specification of ChaCha20 defines only a 256 bit key,
but the
On 2020-01-30 19:25, Dimitry Sibiryakov wrote:
Hello, All.
It looks like FbException has auto-generated (not deleted) default
constructor. Correct me if I'm wrong but if it is thrown constructed
this way, CLOOP envelopes will crash on any access to uninitialized
"status" member.
The
On 2020-01-29 17:21, Dimitry Sibiryakov wrote:
29.01.2020 13:35, Alex Peshkoff via Firebird-devel wrote:
Perhaps I had to go straight to object: is there an example of
IStatus::setWarnings2() usage?
StatusArg.cpp, 292
It doesn't show how to form input status array (sequence of tags
On 2020-01-29 14:25, Dimitry Sibiryakov wrote:
29.01.2020 11:43, Dimitry Sibiryakov wrote:
Just to look at them as an example.
Perhaps I had to go straight to object: is there an example of
IStatus::setWarnings2() usage?
StatusArg.cpp, 292
Firebird-Devel mailing list, web
On 2020-01-29 10:57, Alex Peshkoff via Firebird-devel wrote:
On 2020-01-28 20:01, Dimitry Sibiryakov wrote:
28.01.2020 17:55, Alex Peshkoff via Firebird-devel wrote:
More or less obvious - if sql state to be set explicitly when
raising an exception and should differ from default for used error
On 2020-01-29 13:35, Dimitry Sibiryakov wrote:
29.01.2020 08:57, Alex Peshkoff via Firebird-devel wrote:
You should be able to do something like
(Arg::Warning(isc_...) << Arg::SqlState("01000")).raise();
and after fixing related bugs see that sql state when warning is
display
On 2020-01-28 20:01, Dimitry Sibiryakov wrote:
28.01.2020 17:55, Alex Peshkoff via Firebird-devel wrote:
More or less obvious - if sql state to be set explicitly when raising
an exception and should differ from default for used error code.
Yes, it is obvious but I wonder how to use
On 2020-01-28 19:42, Dimitry Sibiryakov wrote:
Hello, All.
In StatusArgs.h I see definition of SqlState class but no its usage
anywhere. How it is supposed to be used?
More or less obvious - if sql state to be set explicitly when raising an
exception and should differ from default for
On 2020-01-28 17:11, Dimitry Sibiryakov wrote:
28.01.2020 14:55, Alex Peshkoff via Firebird-devel wrote:
in plain C - "const declarations do not produce constant expressions,
i.e. in C you can't use a const int object in a case label",
That's why declarations used to be separ
On 2020-01-28 16:58, Dimitry Sibiryakov wrote:
28.01.2020 13:26, Alex Peshkoff via Firebird-devel wrote:
Do you suggest to move all consts to FirebirdInterface.idl? That's
possible way to go.
I still think that keeping constants in a separate header is better
for flexibility
On 2020-01-28 16:46, Alex Peshkoff via Firebird-devel wrote:
On 2020-01-28 16:41, Dimitry Sibiryakov wrote:
28.01.2020 13:26, Alex Peshkoff via Firebird-devel wrote:
Modern code does not use defines for constants.
Certainly, but the problem is with old one, particular consts_pub.h
On 2020-01-28 16:41, Dimitry Sibiryakov wrote:
28.01.2020 13:26, Alex Peshkoff via Firebird-devel wrote:
Modern code does not use defines for constants.
Certainly, but the problem is with old one, particular consts_pub.h.
It is a matter of one-time copy-paste and search-and-replace
On 2020-01-28 13:36, Adriano dos Santos Fernandes wrote:
On 28/01/2020 07:20, Dimitry Sibiryakov wrote:
28.01.2020 09:52, Alex Peshkoff via Firebird-devel wrote:
Currently that will not work. We have
#define isc_spb_rpr_commit_trans 15
notation in consts_pub.h which is unaffected
On 2020-01-27 19:51, Dimitry Sibiryakov wrote:
27.01.2020 17:45, Alex Peshkoff via Firebird-devel wrote:
Am I understanding right that when ibase.h is included that constants
will be in global namespace as before?
Sure. When you write in Interface.h something like this:
namespace Firebird
On 2020-01-27 19:16, Dimitry Sibiryakov wrote:
27.01.2020 17:08, Alex Peshkoff via Firebird-devel wrote:
What about compatibility with old programs using that constants?
There are several possible cases:
1) The program already included both headers - everything is fine it
will use
On 2020-01-27 18:12, Dimitry Sibiryakov wrote:
Hello, All.
Currently Interface.h includes ibase.h which makes it a strange mix
of two APIs. It was unavoidable in version 3 because that time OO API
missed some essential functionality but now AFAIK it can be
self-sufficient.
IMHO, these
On 2020-01-20 20:08, Dimitry Sibiryakov wrote:
20.01.2020 18:02, Dimitry Sibiryakov wrote:
Run failed for ids_h (63451d8)
Repository: FirebirdSQL/firebird
Workflow: CI
Duration: 23 minutes and 48.0 seconds
Finished: 2020-01-20 17:02:56 UTC
View results
On 2020-01-20 18:14, Dimitry Sibiryakov wrote:
20.01.2020 14:34, Alex Peshkoff via Firebird-devel wrote:
In order not to cause rebuilds files are explicitly compared with old
one. What a problem?
The problem that it is not how MAKE is supposed to work.
Because Firebird doesn't use
On 2020-01-20 15:40, Adriano dos Santos Fernandes wrote:
On 20/01/2020 09:01, Dimitry Sibiryakov wrote:
20.01.2020 12:58, Alex Peshkoff via Firebird-devel wrote:
Adding unzip to env which is able to build firebird (i.e. has working
toolchain) is trivial.
Yes, but you lose ability to update
On 2020-01-20 13:22, Dimitry Sibiryakov wrote:
20.01.2020 10:51, Alex Peshkoff via Firebird-devel wrote:
Build environment missed unzip.
Another reason to keep RES files not compressed.
Not sure. Adding unzip to env which is able to build firebird (i.e. has
working toolchain) is trivial
On 2020-01-20 09:57, Mark Rotteveel wrote:
http://web.firebirdsql.org/download/snapshot_builds/linux/fbtrunk/
currently contain no snapshots.
Build environment missed unzip. I've added utility - lets see does it
help or not.
Firebird-Devel mailing list, web interface at
On 2020-01-19 21:56, Mark Rotteveel wrote:
On 2020-01-19 19:32, Alex Peshkoff via Firebird-devel wrote:
On 2020-01-19 18:58, Adriano dos Santos Fernandes wrote:
- A technical documentation does not need anything more than
markdown offers. Markdown sources are good directly and with tools
On 2020-01-18 12:03, Mark Rotteveel wrote:
On 17-01-2020 15:00, Alex Peshkoff via Firebird-devel wrote:
On 2020-01-17 16:29, Mark Rotteveel wrote:
Hardly any of the documentation in the docs-folder have links, and
you can have links in Markdown.
No named paragraphs. I have no idea how
On 2020-01-17 16:29, Mark Rotteveel wrote:
On 2020-01-17 11:32, Dimitry Sibiryakov wrote:
17.01.2020 08:14, Mark Rotteveel wrote:
That is the whole point of markdown: that it is a human-readable
plain text file that can be converted to better looking HTML or PDF
with a tool.
The main
On 2020-01-17 14:19, Dimitry Sibiryakov wrote:
17.01.2020 12:12, Alex Peshkoff via Firebird-devel wrote:
why?
due to broken windows build?
on posix that works well
AFAIU it is used as an index in some array so it rely that these
arrays are filled in a definite way without field reorder
On 2020-01-17 14:07, Dimitry Sibiryakov wrote:
17.01.2020 12:00, Alex Peshkoff via Firebird-devel wrote:
To reference field by id. Like this:
It looks quite error-prone
why?
due to broken windows build?
on posix that works well
and better to be cleaned out, perhaps. That's why I said
On 2020-01-17 13:53, Dimitry Sibiryakov wrote:
17.01.2020 11:50, Alex Peshkoff via Firebird-devel wrote:
Manually change ids.h ?
No. I cannot remember that I changed it after addition of new fields
in ODS 12.1 but still Avalerion is working.
Is ids.h required for something at all
On 2020-01-17 13:36, Dimitry Sibiryakov wrote:
17.01.2020 09:37, Alex Peshkoff via Firebird-devel wrote:
Do not forget m4. After adding new field to system table it's used to
preprocess relations.h => gen/ids.h .
m4 is not used in Windows build. I wonder how (if) it work with
chan
On 2020-01-16 22:38, Dimitry Sibiryakov wrote:
Back in the day I did try to remove all posix tools from the build and
packaging process. I failed, because it was impossible to replace sed.
I also tried that and also failed but I still think that it is
possible, just some trade-offs must be
On 2020-01-10 11:24, Mark Rotteveel wrote:
On 2020-01-09 14:10, Adriano dos Santos Fernandes wrote:
Better IMO: remove GPRE (and QLI) from the kits.
I don't really see why we should remove it right now. Firebird still
relies on GPRE for its own build, so in that sense, GPRE isn't
On 2020-01-09 16:10, Adriano dos Santos Fernandes wrote:
Better IMO: remove GPRE (and QLI) from the kits.
As far as I know people still use them both for their legacy applications.
Firebird-Devel mailing list, web interface at
https://lists.sourceforge.net/lists/listinfo/firebird-devel
On 2020-01-06 19:32, Dimitry Sibiryakov wrote:
06.12.2019 20:08, Paul Reeves wrote:
But I guess we should upgrade anyway. Perhaps a more pertinent question
would be too ask whether we need to stick with v5. We haven't hacked
the code. We just use InnoSetup from a standard install so there is no
On 2019-12-26 18:43, Mark Rotteveel wrote:
128-bit literal - is it Numeric or Decimal?
Given the lack of an int128, we should consider it an exact numeric
literal of either DECIMAL or NUMERIC. The standard says (5.3 ):
"""
22) The declared type of an ENL is an
implementation-defined
On 2019-12-26 19:01, Mark Rotteveel wrote:
On 26/12/2019 16:43, Mark Rotteveel wrote:
Formally, I take this to mean we should choose one type, eg DECIMAL,
but that would probably not match people assuming that literal
without decimal points are integral literals.
We could consider a middle
On 2019-12-26 17:40, Mark Rotteveel wrote:
On 25/12/2019 12:11, Alex Peshkoff via Firebird-devel wrote:
On 2019-12-11 18:06, Mark Rotteveel wrote:
In other words, it looks like the mapping:
of INTEGER-backed types
1. ignores subtype information and
Ignoring subtype is as designed here
On 2019-12-11 18:06, Mark Rotteveel wrote:
In other words, it looks like the mapping:
of INTEGER-backed types
1. ignores subtype information and
Ignoring subtype is as designed here. The aim of SET BIND is to help
client deal with fields values in cases when it for some reason can not
On 2019-12-23 15:08, Norbert Saint Georges wrote:
Alex Peshkoff via Firebird-devel a écrit :
On 2019-12-12 11:29, Norbert Saint Georges wrote:
Hello everyone,
for the procedures IUtil_loadBlobPtr & iUtil_dumpBlobPtr what type of
field is provided? BFile ??
May be I do not understand
On 2019-12-12 11:29, Norbert Saint Georges wrote:
Hello everyone,
for the procedures IUtil_loadBlobPtr & iUtil_dumpBlobPtr what type of
field is provided? BFile ??
May be I do not understand your question.
There is no 'field' parameter here, there is blob ID which is a pointer
to
On 2019-12-08 17:10, Mark Rotteveel wrote:
For consistency of the grammar, I think it is better if the NATIVE
option is also prefixed with TO,
So instead of SET BIND NATIVE, I think it should be SET BIND
TO NATIVE. This would match with the form of SET BIND TO
LEGACY, and grammatically,
On 2019-12-08 16:56, Mark Rotteveel wrote:
On 08/12/2019 14:39, Simonov Denis via Firebird-devel wrote:
Alex Peshkoff via Firebird-devel
wrote Sun, 08 Dec 2019
15:12:03 +0300:
Thank you, not needed - fixed that.
Fixed, but not completely.
SET BIND OF DECFLOAT(16) NATIVE; -- work OK
401 - 500 of 821 matches
Mail list logo
