property).
Mark
--
Mark Rotteveel
Firebird-Devel mailing list, web interface at
https://lists.sourceforge.net/lists/listinfo/firebird-devel
result set (by
requesting the last row), and if I can't fulfill this requirement, I
need to at least document this.
[1]:
https://docs.oracle.com/en/java/javase/17/docs/api/java.sql/java/sql/ResultSet.html#getRow()
--
Mark Rotteveel
Firebird-Devel mailing list, web interface
On 28-11-2021 08:22, Dmitry Yemanov wrote:
27.11.2021 17:28, Mark Rotteveel wrote:
Correction: it behaves as fetch_next (or fetch_prior) for the amount
of rows that was fetched in the last fetch (or at least some number of
rows buffered on the server).
I can understand needing to take
On 27-11-2021 14:10, Mark Rotteveel wrote:
On 26-11-2021 10:10, Dmitry Yemanov wrote:
I'd appreciate if Mark could test scrollability from the Jaybird side
too (i.e. without fbclient involved), but the new protocol should be
supported for that.
I'm running into some odd behaviour. As soon
subsequent fetch ignores the fetch direction, and
applies fetch_next (or fetch_prior).
Mark
--
Mark Rotteveel
Firebird-Devel mailing list, web interface at
https://lists.sourceforge.net/lists/listinfo/firebird-devel
navigations. Protocol changes
are documented here:
https://github.com/FirebirdSQL/firebird/issues/7051
Are other values than 0 or 1 (CURSOR_TYPE_SCROLLABLE) currently possible
for cursorFlags (flags)?
Mark
--
Mark Rotteveel
Firebird-Devel mailing list, web interface at
https://lists.sourceforge.net
he semantics of supporting data change delta table is a bit
more complex (from a quick read of the standard).
Mark
[1]:
https://firebirdsql.org/file/documentation/release_notes/html/rlsnotes207.html#dml-dsql-returning
--
Mark Rotteveel
Firebird-Devel mailing list, web interface at
https://lists.sourceforge.net/lists/listinfo/firebird-devel
and
20th of August 2021.
Mark
--
Mark Rotteveel
Firebird-Devel mailing list, web interface at
https://lists.sourceforge.net/lists/listinfo/firebird-devel
is acceptable for
a point release and I'm ready to introduce protocol 18 in master for v5.
Opinions, please.
Personally, I think this is better to surface in Firebird 5, than rush
it into Firebird 4.0.1.
Mark
--
Mark Rotteveel
Firebird-Devel mailing list, web interface at
https
On 06-11-2021 08:30, Omacht András wrote:
Hi All,
it's November now.
Any chance of coming out in the near future?
3.0.7 was released October 20, 2020.
Firebird 3.0.8 has been released:
https://firebirdsql.org/en/news/firebird-3-0-8-sub-release-is-available/
Mark
--
Mark Rotteveel
On 2021-11-08 17:54, Adriano dos Santos Fernandes wrote:
On 08/11/2021 12:11, Dmitry Yemanov wrote:
08.11.2021 17:54, Dimitry Sibiryakov wrote:
Nope, I believe the new ID must be generated also by findRequest()
if
the clone was found in the cache.
Will it make impossible to detect
On 2021-10-27 09:55, Dmitry Yemanov wrote:
23.10.2021 17:13, Mark Rotteveel wrote:
If record buffering is hard, it could have been done **without** it.
Then it would have been the choice of the user whether it is worth the
performance implications or not.
So you consider acceptable
On 23-10-2021 15:14, Dimitry Sibiryakov wrote:
Mark Rotteveel wrote 23.10.2021 14:31:
I'm not sure why not.
Because of record buffering it is too hard for a feature with so
little usage.
I disagree, either it should have been implemented fully, or not at all.
If record buffering
l.
I'm not sure why not.
Mark
--
Mark Rotteveel
Firebird-Devel mailing list, web interface at
https://lists.sourceforge.net/lists/listinfo/firebird-devel
On 22-10-2021 21:04, Adriano dos Santos Fernandes wrote:
On 21/10/2021 03:48, Mark Rotteveel wrote:
On 20-10-2021 16:19, Adriano dos Santos Fernandes wrote:
The internal local temporary table.
I'll look into the problem to fix it.
Please try the next snapshot.
Thanks, I can confirm it's
On 20-10-2021 16:19, Adriano dos Santos Fernandes wrote:
On 17/10/2021 08:57, Mark Rotteveel wrote:
I'm making changes to Jaybird to support the new multi-row RETURNING
results.
When using UPDATE OR INSERT ... RETURNING statements in Firebird 5, the
insert count (isc_info_req_insert_count
On 17-10-2021 13:57, Mark Rotteveel wrote:
I'm making changes to Jaybird to support the new multi-row RETURNING
results.
When using UPDATE OR INSERT ... RETURNING statements in Firebird 5, the
insert count (isc_info_req_insert_count) is 2 instead of 1. Jaybird
obtains this count after
On 17-10-2021 13:57, Mark Rotteveel wrote:
I'm making changes to Jaybird to support the new multi-row RETURNING
results.
When using UPDATE OR INSERT ... RETURNING statements in Firebird 5, the
insert count (isc_info_req_insert_count) is 2 instead of 1. Jaybird
obtains this count after
a
count of 1 is reported.
What could be the reason for this difference?
Mark
--
Mark Rotteveel
Firebird-Devel mailing list, web interface at
https://lists.sourceforge.net/lists/listinfo/firebird-devel
nnecessary
keyword.
Technically, I think MAIN doesn't have to be a keyword, it can be the
object name of the tablespace that is the first database file. It will
require some extra handling though, because you can't alter MAIN opposed
to other tablespaces.
Mark
--
Mark Rotteveel
Firebird-Devel ma
for the user - can happen when restoring a backup of
a database you didn't know had tablespaces.
Mark
--
Mark Rotteveel
Firebird-Devel mailing list, web interface at
https://lists.sourceforge.net/lists/listinfo/firebird-devel
3).
Note that in Dialect 1:
0-smallint -> integer
0-integer -> double
Behaviour for dialect 1 can be ignored, because dialect 1 has been
deprecated for 20+ years.
In dialect 3, subtraction between SMALLINT, INTEGER and BIGINT all
results in BIGINT.
Mark
--
Mark Rotteveel
Fir
The range of a smallint is from -32768 to 32767, so
you can't negate -32768 as it will overflow back to -32768, hence it
will raise the integer overflow error.
Mark
--
Mark Rotteveel
Firebird-Devel mailing list, web interface at
https://lists.sourceforge.net/lists/listinfo/firebird-devel
ch has no
authority to 'declare' SRP deprecated.
In other words, this is pure FUD.
Mark
--
Mark Rotteveel
Firebird-Devel mailing list, web interface at
https://lists.sourceforge.net/lists/listinfo/firebird-devel
On 07-10-2021 15:54, Roman Simakov wrote:
чт, 7 окт. 2021 г. в 11:14, Mark Rotteveel :
I think it will save a lot of headaches if ALTER DATABASE {BEGIN|END}
BACKUP can do that for all tablespaces at once. It would be a lot
simpler than having to arrange that per tablespace. That is not to say
On 2021-10-06 21:37, Roman Simakov wrote:
ср, 6 окт. 2021 г. в 19:29, Adriano dos Santos Fernandes
:
And what about nbackup? Will it create a .delta file per tablespace?
Our implementation does not support nbackup yet. At first glance it
might be a special DDL operation like
ALTER
On 2021-10-06 21:27, Roman Simakov wrote:
ср, 6 окт. 2021 г. в 19:13, Mark Rotteveel :
On 06-10-2021 17:32, Roman Simakov wrote:
> 9. ALTER INDEX DROP TABLESPACE
>
> Data of the index will be moved to the main database.
How will this work for indexes backing constraints?
I see no
to have two separate meanings.
Mark
--
Mark Rotteveel
Firebird-Devel mailing list, web interface at
https://lists.sourceforge.net/lists/listinfo/firebird-devel
==
First of all, please let me know whether you agree or not with SYNTAX
and ODS parts. Other opinions and suggestions are welcome as well.
Mark
--
Mark Rotteveel
Firebird-Devel mailing list, web interface at
https://lists.sourceforge.net/lists/listinfo/firebird-devel
On 05-10-2021 17:33, Alex Peshkoff via Firebird-devel wrote:
On 10/5/21 5:49 PM, Mark Rotteveel wrote:
No, I was referring to the fact the OO API in Firebird 3 - according
to the discussion I referenced - does not provide a way to build BPBs.
Exactly.
BTW, if needed it's very simple
On 04-10-2021 11:53, Alex Peshkoff via Firebird-devel wrote:
On 10/3/21 2:25 PM, Mark Rotteveel wrote:
- New OO API (at least in Firebird 3), not providing an explicit way
to create stream blobs (see "[Firebird-devel] IBlob::putSegment" from
27 May 2021)
I suppose you mean t
specific to stream blobs, a concept that's still in the code but
hasn't been used in many years."
In short, what is the actual status of stream blobs, and would it be a
good idea to use them or not?
Mark
--
Mark Rotteveel
Firebird-Devel mailing list, web interface at
https://lists.sourcefor
On 2021-09-13 15:59, Maya Opperman wrote:
Another possibility is to set coercion rules for new data type for
your connection, see
https://firebirdsql.org/file/documentation/release_notes/html/en/4_0/rlsnotes40.html#rnfb4-msql-set-bind-native-to-legacy-coercion-rules
Thanks Vlad! In this
On 2021-09-09 11:57, Dimitry Sibiryakov wrote:
Gabor Boros wrote 09.09.2021 9:36:
3.0.7 released in October 2020.
Snapshots are released daily.
Snapshots are not releases.
Mark
Firebird-Devel mailing list, web interface at
https://lists.sourceforge.net/lists/listinfo/firebird-devel
On 2021-09-02 17:46, Adriano dos Santos Fernandes wrote:
We have still traces of the old error message processing that only
complicate things.
We define errors in .sql files (it was database) and then everything is
as before.
We have generated files in the tree, which frequently causes merge
ebird core developer, which means this is
not my decision).
Mark
--
Mark Rotteveel
Firebird-Devel mailing list, web interface at
https://lists.sourceforge.net/lists/listinfo/firebird-devel
On 2021-09-01 18:20, Alex Peshkoff via Firebird-devel wrote:
On 9/1/21 7:13 PM, Omacht András wrote:
(Or please support D1 and don’t force developers to rewrite existing
codebase.)
May be I've missed something - but did we have plans to remove Dialect
1? It seems that not.
Technically,
On 2021-09-01 15:40, Molnár Attila wrote:
Ok, I understand it's not "wrong", works as designed/intended. Just
put into documentation.
Also, how do you expect to people to leave dialect 1 when dialect 3
gives no benefit, in both dialect extra effort needed to get
calculations right, plain
On 2021-08-31 21:10, Dimitry Sibiryakov wrote:
Mark Rotteveel wrote 31.08.2021 19:05:
What does SQL standard say about it?
Not much, beyond "iv) The precision and scale of the result of
division are implementation-defined."
So theoretically result of division of two exact n
ision and scale of the result of division
are implementation-defined."
Mark
--
Mark Rotteveel
Firebird-Devel mailing list, web interface at
https://lists.sourceforge.net/lists/listinfo/firebird-devel
t such behaviour, then you need to either stay on dialect 1,
or cast one of the operands explicitly to double precision.
Mark
--
Mark Rotteveel
Firebird-Devel mailing list, web interface at
https://lists.sourceforge.net/lists/listinfo/firebird-devel
also choose to return the 'best' value (i.e. insert
count for INSERT, update count for UPDATE, delete count for DELETE,
insert + update count for UPDATE OR INSERT, and insert + update + delete
counts for MERGE).
Mark
--
Mark Rotteveel
Firebird-Devel mailing list, web interface at
https
or not.
I think this was in response to my idea to introduce a new info item
that reported the real statement type next to isc_info_sql_stmt_type
which now more functions as 'how to handle the response'.
Mark
--
Mark Rotteveel
Firebird-Devel mailing list, web interface at
https
On 2021-08-19 16:43, Dmitry Yemanov wrote:
19.08.2021 17:30, Mark Rotteveel wrote:
If we want/need some API to correctly identify the type of statement
even when RETURNING is present, we would need to add yet another info
item (e.g. isc_info_sql_stmt_type2 or isc_info_sql_real_stmt_type
On 2021-08-19 15:17, Adriano dos Santos Fernandes wrote:
Since RETURNING was created, we change values of isc_info_sql_stmt_type
so clients can understand that statements with RETURNING have values.
With GH-6815, RETURNING will return cursors (except for INSERT INTO ...
VALUES RETURNING which
On 14-08-2021 21:26, Roman Simakov wrote:
I think it's a good idea to keep not only limits but the formulas for
their calculations.
Already done for the maximum file size and maximum index key size.
Mark
--
Mark Rotteveel
Firebird-Devel mailing list, web interface at
https
On 14-08-2021 09:12, Dmitry Yemanov wrote:
14.08.2021 10:02, Mark Rotteveel пишет:
Now I see you mentioned 32 TB as the database size limit. How was it
calculated? It should be the same 128 TB, AFAIK.
The 32 TB is the old value on the page, when the entire page was for
Firebird 2.5. I have
On 14-08-2021 08:49, Dmitry Yemanov wrote:
13.08.2021 10:04, Mark Rotteveel wrote:
I'd still like an answer to the following questions (assume page size
32KB for all):
- What is the maximum file size of a Firebird 4 database
Theoretically unlimited (depends on OS and filesystem
On 06-08-2021 14:27, Mark Rotteveel wrote:
I'm looking at updating
https://firebirdsql.org/en/firebird-technical-specifications/, but I'm
wondering if anything changed for some of the sizes listed on that page.
Specifically, does the introduction of page size 32KB change anything
On 06-08-2021 14:37, Jiří Činčura wrote:
Definitely BLOB size should be bigger. Index key length too.
The listed blob size is even wrong for Firebird 2.5. I created a 128 GB
blob on Firebird 2.5 with page size 16KB. I wonder if it intended to say
>32GB instead of <32GB.
Mark
-
On 07-08-2021 11:38, Dmitry Yemanov wrote:
07.08.2021 12:31, Mark Rotteveel wrote:
Currently, for blobs that are 4GB or longer, OCTET_LENGTH will
silently truncate the length. This means that a 4GB blob is reported
as length 0, a 5GB blob as 1,073,741,824.
It's not OCTET_LENGTH who's guilty
a signal value
(e.g. -1)?
Mark
--
Mark Rotteveel
Firebird-Devel mailing list, web interface at
https://lists.sourceforge.net/lists/listinfo/firebird-devel
On 06-08-2021 18:20, Dimitry Sibiryakov wrote:
06.08.2021 18:11, Mark Rotteveel wrote:
That document says <32GB for blob, if it is restricted to unit32, then
the limit should be <4GB, right?
Limit is 4GB for corresponding info item. The BLOB itself can be
longer if you "just
On 06-08-2021 16:16, Dimitry Sibiryakov wrote:
06.08.2021 14:55, Mark Rotteveel wrote:
What would be the new max size of blobs?
Nothing changed about BLOBs. It is still limited to uint32 for total
size and seek location.
That document says <32GB for blob, if it is restricted to uni
On 06-08-2021 14:37, Jiří Činčura wrote:
Definitely BLOB size should be bigger. Index key length too.
Good point, index key length I was aware of. What would be the new max
size of blobs?
Mark
--
Mark Rotteveel
Firebird-Devel mailing list, web interface at
https://lists.sourceforge.net
? Do they double?
What about maximum number of rows per table?
Mark
--
Mark Rotteveel
Firebird-Devel mailing list, web interface at
https://lists.sourceforge.net/lists/listinfo/firebird-devel
On 2021-08-03 10:28, Gabor Boros wrote:
Nice idea but this feature useless in current form.
The documentation say:
"Table RDB$CONFIG is populated from in-memory structures upon request
and its instance is preserved for the SQL query lifetime. For security
reasons, access to this table is
On 23-07-2021 10:26, Mark Rotteveel wrote:
On 23-07-2021 10:06, Vlad Khorsun wrote:
23.07.2021 10:50, Mark Rotteveel wrote:
Hi,
Last week a question was asked on firebird-java regarding a JVM crash
on Linux when Firebird Embedded is used in combination with a UDF,
but to be honest, I have
On 23-07-2021 10:06, Vlad Khorsun wrote:
23.07.2021 10:50, Mark Rotteveel wrote:
Hi,
Last week a question was asked on firebird-java regarding a JVM crash
on Linux when Firebird Embedded is used in combination with a UDF, but
to be honest, I have no clue what to look for.
I have been able
) with the application and basic UDF provided by the OP. Can
someone look at https://groups.google.com/g/firebird-java/c/22G7zPGNnkY?
Mark
--
Mark Rotteveel
Firebird-Devel mailing list, web interface at
https://lists.sourceforge.net/lists/listinfo/firebird-devel
According to the Firebird Language Reference[1], the
RDB$RELATION_FIELDS.RDB$UPDATE_FLAG signals whether a column is a
computed column (0) or a regular column (1) (or I guess, updatable (1)
vs not-updatable (0)). In practice, this doesn't seem to be the case
(see
On 2021-07-06 12:12, Alex Peshkoff via Firebird-devel wrote:
Not understand your question.
4 packets were sent:
1. op_connect
2. op_attach
3. op_cont_auth
4. op_cont_auth
What is op_connect + op_attach?
The op_connect packet has a secondary op_attach code.
Mark
Firebird-Devel mailing
On 2021-07-06 07:45, Jiří Činčura wrote:
This is the order of operations. Compression is disabled. FB3 server
has only Srp and Win_Sspi enabled, WireCrypt is Enabled.
op_connect + op_attach
CNCT_user, ...
CNCT_host, ...
CNCT_user_verification,
CNCT_login, ...
CNCT_plugin_name, Srp256
phases that r2dbc-firebird
uses to connect. The INITIAL phase handles the response to the connect
(op_connect) message.
Mark
--
Mark Rotteveel
Firebird-Devel mailing list, web interface at
https://lists.sourceforge.net/lists/listinfo/firebird-devel
On 2021-07-05 16:55, Jiří Činčura wrote:
What's the expected response to server from client after client
receives op_accept_data?
Have you looked at the Jaybird code? As far as I'm aware, I have all
phases and possible roundtrip combinations implemented there.
Alternatively, I could commit
/lists/listinfo/firebird-devel, or by
sending an email to firebird-devel-requ...@lists.sourceforge.net with
subject unsubscribe.
Mark
--
Mark Rotteveel
Firebird-Devel mailing list, web interface at
https://lists.sourceforge.net/lists/listinfo/firebird-devel
On 2021-06-24 08:16, Omacht András wrote:
Hi!
I don't know if this is the right list for the documentation. Sorry if
not.
The right list for documentation is the firebird-docs list.
Mark
Firebird-Devel mailing list, web interface at
LSTATE = HY000
exception 1
-GL_EX
-Exception message
-At procedure 'EX' line: 9, col: 3
SQL> execute procedure ex('Exception') || ' message';
Statement failed, SQLSTATE = HY000
exception 1
-GL_EX
-Exception message
-At procedure 'EX' line: 9, col: 3
SQL>
--
Mark Rotteveel
Firebird-Devel maili
On 2021-06-01 11:51, Dimitry Sibiryakov wrote:
31.05.2021 21:21, Adriano dos Santos Fernandes wrote:
[ | ( ) ]
[ RETURNING_VALUES |
RETURNING_VALUES ( ) |
RETURNING [ INTO ] ]
This does not support ignore all output in DSQL.
There can be syntax "RETURNING
On 2021-05-31 18:34, Dmitry Yemanov wrote:
31.05.2021 17:49, Dimitry Sibiryakov пишет:
31.05.2021 16:19, Alex Peshkoff via Firebird-devel wrote:
Dimitry, can you provide standard syntax for others to compare?
https://ronsavage.github.io/SQL/sql-2003-2.bnf.html#call%20statement
As far as I
re). Again, for syntax consistency, we should consider allowing
this everywhere `RETURNING` occurs, where it would signal the 'normal'
behaviour.
Mark
--
Mark Rotteveel
Firebird-Devel mailing list, web interface at
https://lists.sourceforge.net/lists/listinfo/firebird-devel
` output in Firebird 3.0.
Why don't these commands work? Am I missing some arguments to make these
commands work? If so, what are these arguments?
Mark
--
Mark Rotteveel
Firebird-Devel mailing list, web interface at
https://lists.sourceforge.net/lists/listinfo/firebird-devel
led
against the API (point 2) will break if you change something from signed
to unsigned.
Mark
--
Mark Rotteveel
Firebird-Devel mailing list, web interface at
https://lists.sourceforge.net/lists/listinfo/firebird-devel
ho do know the correct terminology in cryptography, and make it harder
to find correct information.
Mark
--
Mark Rotteveel
Firebird-Devel mailing list, web interface at
https://lists.sourceforge.net/lists/listinfo/firebird-devel
?
Mark
--
Mark Rotteveel
Firebird-Devel mailing list, web interface at
https://lists.sourceforge.net/lists/listinfo/firebird-devel
, if `IV GENERATED` is specified for DECRYPT, it should take
the first (IV/block size) bytes of the input as the IV and use that for
decryption.
Thoughts?
Mark
--
Mark Rotteveel
Firebird-Devel mailing list, web interface at
https://lists.sourceforge.net/lists/listinfo/firebird-devel
where it has advantage of a single
entry point.
That doesn't match the intent expressed elsewhere in this thread to
introduce features/types that are only accessible through the new API.
Mark
--
Mark Rotteveel
Firebird-Devel mailing list, web interface at
https://lists.sourceforge.net/lists
On 22-05-2021 09:19, Dmitry Yemanov wrote:
22.05.2021 10:06, Mark Rotteveel wrote:
The majority of our users probably still use the old API, either
directly or indirectly. Given the undocumented state of the new API, I
suspect it does not see a lot of usage, nor will it unless that changes
users?
Mark
--
Mark Rotteveel
Firebird-Devel mailing list, web interface at
https://lists.sourceforge.net/lists/listinfo/firebird-devel
On 21-05-2021 22:39, Alex Peshkoff via Firebird-devel wrote:
On 5/21/21 9:06 PM, Mark Rotteveel wrote:
On 2021-05-21 16:51, Alex Peshkoff via Firebird-devel wrote:
We have one more unused value for size - zero, we do not support
characters with length == 0.
We may store logical data length - 1
On 2021-05-21 16:51, Alex Peshkoff via Firebird-devel wrote:
We have one more unused value for size - zero, we do not support
characters with length == 0.
We may store logical data length - 1, this will make it possible to
have exactly 64Kb fields, which (I believe) can be useful in some
cases.
On 2021-05-20 08:28, Omacht András wrote:
Mark: Yes, that could be good, but it’s not even in 4.0, so (one day)
we wouldn’t be able to switch to 5.0 by rewriting these calls first.
For the time being, the original plan remains: writing a function,
replacing udf calls with it ...
Or rewrite
On 2021-05-19 18:33, Nils Bödeker wrote:
Hello
as user opinion (sorry)
We still using UDFs.
Own written and external like this one
http://freeadhocudf.org [1]
For us, UDF support should be still in FB 5.
I'd recommend rewriting your own UDFs to UDRs, the replacement feature
for UDFs. As
On 2021-05-19 19:40, Omacht András wrote:
Hi!
Since Firebird 2.5, we have been able to replace almost all UDFs with
built-in functions.
There is only one left (it’s the Highlander :)) : formatting dates
and timestamps to readable format for hungarian people:
-- Hungarian format
select
On 2021-05-19 11:49, Dmitry Yemanov wrote:
19.05.2021 12:27, Alex Peshkoff via Firebird-devel wrote:
I have the same question about dialect 1
A few years ago it was discussed but people continued (at least
continued that time) to use it...
Same as item 1 above. We can do it now, but
On 2021-05-19 12:35, Adriano dos Santos Fernandes wrote:
On 19/05/2021 06:27, Alex Peshkoff via Firebird-devel wrote:
Let me also add suggest gsec and related services - was deprecated in
fb3.
I'll not be strongly against, as I (and TCS) could probably adapt, but
I
always used it to add
in the log is more 'friendly', but might go unnoticed.
Mark
--
Mark Rotteveel
Firebird-Devel mailing list, web interface at
https://lists.sourceforge.net/lists/listinfo/firebird-devel
in databases.conf.
I'm not sure if the first or the last one wins, but based on your
comments, it seems to be the first.
Mark
--
Mark Rotteveel
Firebird-Devel mailing list, web interface at
https://lists.sourceforge.net/lists/listinfo/firebird-devel
On 13-05-2021 16:35, Alex Peshkoff via Firebird-devel wrote:
On 5/13/21 3:47 PM, Mark Rotteveel wrote:
2. Exact numeric literals with 30 or more digits are handled as
DECFLOAT(34), they should be handled as INT128 or DECIMAL/NUMERIC
backed by INT128 (as those types support 38 digits; actually
-precision numerics were backed by DECFLOAT?
Mark
--
Mark Rotteveel
Firebird-Devel mailing list, web interface at
https://lists.sourceforge.net/lists/listinfo/firebird-devel
On 2021-05-11 21:09, Dimitry Sibiryakov wrote:
11.05.2021 18:42, Mark Rotteveel wrote:
As far as I understand PSS, it will hash the message-hash + a
generated salt (+ maybe some more operations)
I see no hash operation in the PSS white paper, only some bit mixing
with salt.
I assume the G
On 11-05-2021 18:34, Dimitry Sibiryakov wrote:
11.05.2021 18:10, Mark Rotteveel wrote:
It doesn't explain why
Ah, now I get it. The function doesn't hash anything itself, this
parameter just inform it which kind of hash it has on input and thus it
must match the hash function used
On 11-05-2021 17:49, Alex Peshkoff via Firebird-devel wrote:
Please suggest that in admin. I promise to make required changes during
24 hours after decision.
Done
--
Mark Rotteveel
Firebird-Devel mailing list, web interface at
https://lists.sourceforge.net/lists/listinfo/firebird-devel
b.com/libtom/libtomcrypt/releases/download/v1.18.2/crypt-1.18.2.pdf
--
Mark Rotteveel
Firebird-Devel mailing list, web interface at
https://lists.sourceforge.net/lists/listinfo/firebird-devel
On 11-05-2021 17:55, Dimitry Sibiryakov wrote:
11.05.2021 17:41, Mark Rotteveel wrote:
Then I propose to at least rename the function to RSA_SIGN_HASH so it
1) matches the TomCrypt function name it basically calls directly, and
2) makes clear that it doesn't sign a message, but a hash
On 11-05-2021 17:33, Alex Peshkoff via Firebird-devel wrote:
On 5/11/21 6:24 PM, Mark Rotteveel wrote:
And I repeat: given RSA_SIGN has a HASH parameter, and applies PSS, I
assume it hashes the message using the supplied (or default) hash
algorithm, and then signs the resulting hash. Having
A_SIGN.
And I repeat: given RSA_SIGN has a HASH parameter, and applies PSS, I
assume it hashes the message using the supplied (or default) hash
algorithm, and then signs the resulting hash. Having to hash this
yourself makes no sense to me.
Mark
--
Mark Rotteveel
Firebird-Devel mailing lis
On 2021-05-11 11:51, Alex Peshkoff via Firebird-devel wrote:
That may work only for very short (like in a sample) 'Test message'-
for real-size messages hash is used for signing. rsa_sign just would
not work with too long argument.
Also take into an account - different people need different
On 2021-05-11 11:44, Alex Peshkoff via Firebird-devel wrote:
On 5/10/21 12:48 PM, Mark Rotteveel wrote:
How was the maximum size of the result of RSA_PRIVATE and RSA_PUBLIC
determined?
To have solid reserve.
A reserve of a factor 3+ for private and 7+ for public seems a bit
excessive to me
$get_context('USER_SESSION', 'private_key'))) from rdb$database;
```
And similar for RSA_VERIFY.
Mark
--
Mark Rotteveel
Firebird-Devel mailing list, web interface at
https://lists.sourceforge.net/lists/listinfo/firebird-devel
101 - 200 of 1483 matches
Mail list logo
