Thread: UUID with variable length

UUID with variable length

From
Dirk Krautschick
Date:
Hi,

I have here a situation with the usage of UUID. Here the database user allows UUIDs with less then 16 byte lengths
(pleasedon't ask :-) ).
 

Of course there are some technical ways to do the filling of the not used bytes but I hope there is a better solution.
ThisUUID is used
 
as primary Key and for indexing.

CHAR 16 is not preferred because of the risk of mistakenly changing the binary data.

Another option would be e.g. bytea but how is good would it work from a IO an latency perspective.

Or do you have some other ideas how to use a primary key datatype like UUID but with variable length?

Thanks

Dirk

Re: UUID with variable length

From
Christophe Pettus
Date:

> On Oct 15, 2020, at 13:49, Dirk Krautschick <Dirk.Krautschick@trivadis.com> wrote:
> Or do you have some other ideas how to use a primary key datatype like UUID but with variable length?

You're probably best off storing it as a VARCHAR() with a check constraint or constraint trigger that validates it.

--
-- Christophe Pettus
   xof@thebuild.com




Re: UUID with variable length

From
Stephen Frost
Date:
Greetings,

* Christophe Pettus (xof@thebuild.com) wrote:
> > On Oct 15, 2020, at 13:49, Dirk Krautschick <Dirk.Krautschick@trivadis.com> wrote:
> > Or do you have some other ideas how to use a primary key datatype like UUID but with variable length?
>
> You're probably best off storing it as a VARCHAR() with a check constraint or constraint trigger that validates it.

Surely a bytea would be better and be less overhead than storing it as
text..

Thanks,

Stephen

Attachment

Re: UUID with variable length

From
Alvaro Herrera
Date:
On 2020-Oct-15, Dirk Krautschick wrote:

> Hi,
> 
> I have here a situation with the usage of UUID. Here the database user
> allows UUIDs with less then 16 byte lengths (please don't ask :-) ).
> 
> Of course there are some technical ways to do the filling of the not
> used bytes but I hope there is a better solution. This UUID is used as
> primary Key and for indexing.

How much shorter than 16 bytes are you expecting your UUIDs to be?  If
they're not short enough, you'll still have to store a lot of padding
space, and considering that you'll need a length indicator if you use
variable length, it does not really sound like you'll save much actual
space.  And you'll definitely be getting a slower datatype, since doing
operations will become more complex.

If this were me, I would see about zeroing out the unused bytes and not
waste a lot of developer time on this.