Gevik Babakhani wrote:
> LIKE could come handy if someone wants to abuse the uuid datatype to
> store MD5 hash values. However I am not going to implement it if there
> is no need for that (assuming it will pass the acceptance test)
>
>
Perhaps providing LIKE just to encourage abuse is not such a good idea?
IMHO, a GUID should be comparable for equality and NULL only, not LIKE.
I also think that ordering is feasible only when looking at parts of the
GUID, i.e. order by the result of a function that extracts a timestamp
or a node-address. Magnitude comparison on the GUID as a whole makes no
sense to me.
Regards,
Thomas Hallgren
> On Mon, 2006-09-18 at 10:06 +0200, Thomas Hallgren wrote:
>
>> Gevik Babakhani wrote:
>>
>>> To my opinion GUIDs type need to provide the following in the database.
>>>
>>> 1. GUID type must accept the correct string format(s), with of without
>>> extra '-'
>>> 2. GUID type must internally be stored as small as possible.
>>> 3. GUID type must be comparable with == , != , LIKE and (NOT) IS NULL
>>> 4. GUID type must have the ability to be indexed, grouped, ordered,
>>> DISTINCT... but not MAX(), MIN() or SUM()....
>>>
>>>
>> Where do you see a need for LIKE on a GUID?
>>
>> Regards,
>> Thomas Hallgren
>>
>>
>>
>
>
