Re: [Firebird-devel] HASH function (CORE-4436)

2017-07-19 Thread Dimitry Sibiryakov
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.

Re: [Firebird-devel] HASH function (CORE-4436)

2017-07-19 Thread Alex via Firebird-devel
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

[Firebird-devel] [FB-Tracker] Created: (CORE-5587) Size of char (maby varchar) is wrong in multiple client library

2017-07-19 Thread Reydy Valentin (JIRA)
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

Re: [Firebird-devel] HASH function (CORE-4436)

2017-07-19 Thread Adriano dos Santos Fernandes
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

Re: [Firebird-devel] HASH function (CORE-4436)

2017-07-19 Thread Mark Rotteveel
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

Re: [Firebird-devel] HASH function (CORE-4436)

2017-07-19 Thread Adriano dos Santos Fernandes
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

Re: [Firebird-devel] HASH function (CORE-4436)

2017-07-19 Thread Adriano dos Santos Fernandes
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. >

Re: [Firebird-devel] HASH function (CORE-4436)

2017-07-19 Thread Adriano dos Santos Fernandes
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

Re: [Firebird-devel] HASH function (CORE-4436)

2017-07-19 Thread Dmitry Yemanov
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()

[Firebird-devel] [FB-Tracker] Created: (CORE-5588) DbInfo interface is not passed to ancillary instances of plugin

2017-07-19 Thread Alexander Peshkov (JIRA)
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

Re: [Firebird-devel] HASH function (CORE-4436)

2017-07-19 Thread Leyne, Sean
> > 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.