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
---------------------------(end of broadcast)---------------------------
TIP 2: Don't 'kill -9' the postmaster
