>>> devdb=# select * from tbluuid;
>>> pk |
>>> ----------------------------------+
>>> 6b13c5a1afb4dcf5ce8f8b4656b6c93c |
>>> 01e40a79b55b6e226bffb577e960453d |
>>> (2 rows)
>> The UUID standards define a single perfectly clear format, and the one
>> you show is not it.
>>
>>> I was wondering if we want to have a formatting function to be able
>>> to provide other common formats of the uuid/guid?
>> If you stick to the standard format, I don't think that will be
>> necessary.
>
> +1. For people that care about the non-standard MSSQL format, they can
> easily create their own function that will wrap it in {}.
Having been reading through this thread, I was about to make the above
points, but was glad to see that I was beaten to it.
The dashless format is neither standards compliant nor compatible with
other databases that have uuid functions (notably MS SQL Server and
MySQL), nor with microsoft tools where they're used frequently.
(ignoring the {} wrapping stuff which is trivial).
If we add a UUID type to core, I think that a vast majority of the
people who are going to want to use it out there will be expecting the
standard format with dashes. And asking them to put a formatting
function into every query is beyond horrific.
If we want a general raw hex type then let's call it something else,
because calling it UUID will just confuse people. Everyone else follows
the standard on this; we should too.
Tom