On 2020-08-10 18:57, Mark Rotteveel wrote:
On 10-08-2020 17:17, Vlad Khorsun wrote:
Same function returning different types depending on input
argument - very bad idea,
I think.
Not always. For example - ENCRYPT/DECRYPT may return blob or string
value depending upon input datatype and I see nothing bad with this. But
what about particular HASH() - here return type will depend not upon
input type but upon additional parameter, and I agree - that's rather
artificial.
If we have some in the past it doesn't means we should add more mess
"just
because we can".
Except it isn't really an input argument. It is a keyword that defines
the behaviour (and the type) of the function. This is similar to for
example EXTRACT:
- EXTRACT(MILLISECOND FROM sometimestamp) returning NUMERIC(9,1)
- EXTRACT(SECOND FROM sometimestamp) returning NUMERIC(9,4)
- EXTRACT(WEEK FROM sometimestamp) returning SMALLINT (same goes for
most (all?) other types)
Is it possible to pass hash method as parameter ? If not now -
could it be possible
in the feature ? If yes - what type of result HASH should return for
CRC32 in this case
(i.e. when method name is passed as parameter) ?
The current behaviour would already 'break' in this situation, because
the length of the return value already depends on the type passed. So
if we are going to allow parameterization with an expression, that is
already a problem.
In any case that could be tackled because HASH(<expression> USING
<expression>) is a different function than HASH(<expression> USING
<keyword-hash-names>) and thus can have different return type (eg
VARBINARY that is long enough for all hashes), then HASH(<expression>
USING 'CRC32') would return say a VARBINARY(64) with 4 bytes, while
HASH(<expression> USING CRC32) returns an INTEGER.
Good way to make CRC32 useless - it's typically used to calculate
indices in hash tables. Is it convenient to work with VARBINARY here?
On contrary - for crypto-hashes your suggestion works fine.
Ideal, no, but pretty reasonable IMHO. Assuming we would even want
such functionality.
A lot of cryptographic systems let use different hashes in same place
(starting with tomcrypt used in FB). That makes sense - name of
cryptographic hash to use may come with encrypted/signed message.
What about CRC32 - no, it's never used as cryptographic hash, and it's
name can not be passed in such places. Tomcrypt is using separate
function to work with CRC32.
Currently, HASH supports MD5, SHA1, SHA256 and SHA512 - all these
algorithms are used
in cryptography, as Mark said in start message of this thread. Why
mix CRC32 in here ?
It is completely different alg for different purposes. What problem
we want to address
here ? BTW, any plans to add CRC64 ?
Nothing in the name of HASH suggests that all hashes applied must be
cryptographic. Currently HASH also supports PJW (as in HASH(value))
which is non-cryptograhic. We could even make this explicit by adding
HASH(value USING PJW) as an alias for HASH(value).
That old form is kept for backward compatibility. If your suggestion
comes true (hope not) some idiot may try to use PJW as cryptographic hash.
To summarize - I withdraw my initial agreement to add CRC32 calculation
to function HASH(). The only argument for this is same name in plain
english for different purpose things.
Firebird-Devel mailing list, web interface at
https://lists.sourceforge.net/lists/listinfo/firebird-devel
