Wrong formatting of "Elapsed time" in isql
--
Key: CORE-5586
URL: http://tracker.firebirdsql.org/browse/CORE-5586
Project: Firebird Core
Issue Type: Bug
Components: ISQL
Affects
18.07.2017 22:00, Leyne, Sean wrote:
Would this approach have any performance advantages over using UDFs?
People hate writing UDFs for common tasks. And IMHO getting a robust
hash belongs to this category.
Dmitry
18.07.2017 21:55, Adriano dos Santos Fernandes wrote:
We have HASH function that returns a 64 bit integer. The algorithm is
bad and the result too small for a hash.
Yes, and we have CORE-4436 with related complains.
I propose to extend the same function with a second parameter with the
18.07.2017 21:52, Adriano dos Santos Fernandes wrote:
It will be described as VARCHAR, so real length depends on the algorithm
used by the user.
Index is built on full data length, not real one.
--
WBR, SD.
--
18.07.2017 21:55, Adriano dos Santos Fernandes wrote:
Hi!
We have HASH function that returns a 64 bit integer. The algorithm is
bad and the result too small for a hash.
I propose to extend the same function with a second parameter with the
algorithm name.
> When only one parameter is passed,
18.07.2017 21:32, Dmitry Yemanov wrote:
Would it make sense to reserve more bytes, 256 or 1024 octets for example? Just to avoid
extending the result every five years...
Just take care not to overflow index limit.
--
WBR, SD.
> We have HASH function that returns a 64 bit integer. The algorithm is bad and
> the result too small for a hash.
>
> I propose to extend the same function with a second parameter with the
> algorithm name.
>
> When only one parameter is passed, things works as now.
>
> When two parameters
On 18/07/2017 16:32, Dmitry Yemanov wrote:
>
>
>> When two parameters are passed, it will return a VARCHAR(64) CHARACTER
>> SET OCTETS. That's sufficient for a SHA-256, for example.
>
> Would it make sense to reserve more bytes, 256 or 1024 octets for
> example? Just to avoid extending the result
Hi!
We have HASH function that returns a 64 bit integer. The algorithm is
bad and the result too small for a hash.
I propose to extend the same function with a second parameter with the
algorithm name.
When only one parameter is passed, things works as now.
When two parameters are passed, it
On 18/07/2017 16:34, Dmitry Yemanov wrote:
> 18.07.2017 22:00, Leyne, Sean wrote:
>>
>> Would this approach have any performance advantages over using UDFs?
>
> People hate writing UDFs for common tasks. And IMHO getting a robust
> hash belongs to this category.
>
Moreover, we already have HASH
Em 18/07/2017 17:35, Vlad Khorsun via Firebird-devel escreveu:
>
> Algorithm name could define result length.
Yes, for constants.
> If alg name is passed as
> parameter, we could use maximum known length (of all known algs) at
> prepare time.
>
Maximum known length means if a new
Em 18/07/2017 16:58, Dimitry Sibiryakov escreveu:
> 18.07.2017 21:52, Adriano dos Santos Fernandes wrote:
>> It will be described as VARCHAR, so real length depends on the algorithm
>> used by the user.
>
> Index is built on full data length, not real one.
>
People will not be crazy to create
19.07.2017 01:32, Adriano dos Santos Fernandes wrote:
Algorithm name could define result length.
Yes, for constants.
We need to decide whether the algorithm name can be passed dynamically
(and thus be presented as "value" in the grammar) or must be predefined
(via a string literal or
13 matches
Mail list logo
