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.

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?

Thomas Hallgren

---------------------------(end of broadcast)---------------------------
TIP 2: Don't 'kill -9' the postmaster

Reply via email to