19.07.2017 2:47, Adriano dos Santos Fernandes wrote:
They will store hash on field of appropriate length for the given hash
and index it.
On contrary, there is no point to store hash value if its purpose is to speed up lookup
only.
--
WBR, SD.
On 19.07.2017 14:07, Adriano dos Santos Fernandes wrote:
On 19/07/2017 02:29, Dmitry Yemanov wrote:
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
Size of char (maby varchar) is wrong in multiple client library
---
Key: CORE-5587
URL: http://tracker.firebirdsql.org/browse/CORE-5587
Project: Firebird Core
Issue Type: Bug
On 19/07/2017 16:48, Mark Rotteveel wrote:
>
>> If we are not going to use hash plugins I'd vote for this syntax.
>
> I don't think this solution/syntax would disallow the possibility to
> handle this through plugins.
>
You are right. Algorithm name is a recognized at prepare time.
It can be
On 2017-07-19 13:00, Adriano dos Santos Fernandes wrote:
On 19/07/2017 05:27, Dimitry Sibiryakov wrote:
19.07.2017 2:47, Adriano dos Santos Fernandes wrote:
They will store hash on field of appropriate length for the given
hash
and index it.
On contrary, there is no point to store hash
On 19/07/2017 15:42, Mark Rotteveel wrote:
>
>> HASH(X USING MD5) is self-documentary as well.
>
> Yes, it does improve readability.
>
> BTW: can I assume the hash functions will be binary (use OCTETS), and
> not hex encoded values?
>
Yes!
Adriano
On 19/07/2017 05:27, Dimitry Sibiryakov wrote:
> 19.07.2017 2:47, Adriano dos Santos Fernandes wrote:
>> They will store hash on field of appropriate length for the given hash
>> and index it.
>
> On contrary, there is no point to store hash value if its purpose is
> to speed up lookup only.
>
On 19/07/2017 02:29, Dmitry Yemanov wrote:
> 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
19.07.2017 17:44, Leyne, Sean wrote:
Why do we need to extend the current function?
Why not create separate, built-in, functions for each hash type with names*
that align with the common algorithm name?
MD2()
...
MD5()
SHA0()
SHA1()
SHA_224()
...
SHA512_256()
...
SHA3_224()
...
SHA3_512()
DbInfo interface is not passed to ancillary instances of plugin
---
Key: CORE-5588
URL: http://tracker.firebirdsql.org/browse/CORE-5588
Project: Firebird Core
Issue Type: Bug
> > 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 maybe token). The latter gives us
> > more flexibility regarding the result type.
>
> This is an interesting idea.
11 matches
Mail list logo