Tom Lane wrote:The cool thing about a 'GUID' (or in my example a hashed sequence number [sure
Adding an MD5 hash contributes *absolutely zero*, except waste of space, to any attempt to make a GUID. The hash will add no uniqueness that was not there before.
toss in some entropy if you want it]) is that if you happen to reference that
value as a primary key on a table, the URL that passes the argument can not
be guessed at easily. For example using a sequence:
http://domain.com/application/load_record.html?customer_id=12345
Then, users of the web will assume that you have at most 12345 customers. And
they can try to look up information on other customers by doing:
http://domain.com/application/load_record.html?customer_id=12346 http://domain.com/application/load_record.html?customer_id=12344
...basically walking the sequence. Sure, you will protect against this with
access rights, BUT...seeing the sequence is a risk and not something you want
to happen. NOW, if you use a GUID:
http://domain.com/application/load_record.html?customer_id=f46d6296-5362-2526-42e3-1b8ce9dcccc1
Right, so now try to guess the next value in this sequence. It's a little more protective and obfuscated (an advantage in using GUIDs).
Dante
---------------------------(end of broadcast)---------------------------
TIP 9: the planner will ignore your desire to choose an index scan if your
joining column's datatypes do not match
